↗
Russell Keith-Magee
Russell Keith-Magee created BeeWare to fill a gap in his own process. Today, BeeWare is the go-to project for supporting Python on every platform.
Read more
→
BeeWare started about four years because I wanted a debugger for my Python code.
I grew up learning to code using the Borland suite of tools (Turbo C, Turbo Pascal and so on). Since it was the late 80s, they were all console based but they had a really good editor and debugger built in. Over time, I moved to Linux and was introduced to gdb, which is an incredibly powerful debugger, but has an almost toxic user interface by comparison to contemporaneous tools. Python’s built-in debugger (pdb) is similarly powerful, but has also inherited gdb’s toxic user interface.
I wanted to bring the full modern graphical UI experience to these tools. But I wanted to do that while preserving the Python development experience. That meant the tool had to be easily installable from the Python Package Index (PyPI), and also that the tool had to be pure Python.
Four years later, I have inadvertently become the go-to project for supporting Python on every platform known to humanity, and BeeWare is the umbrella label covering all this work. Eventually, I’m hoping to get around to writing the debugger I wanted to write in the first place.
My current contract gives me 40% of my paid time to work on BeeWare projects. I also spend about 20 hours a week of personal time on top of that. Most of the tasks on my to-do list relate to making sure everyone else can contribute to BeeWare:
This process of helping everyone else also guides where I spend my own contribution time. Depending on the situation I might:
To try to promote the project and look out for its long term viability, I also:
The obvious answer would be the diverse technical skills I’ve had to develop in order to get Python code running on iOS, Android, browsers, and so on. But honestly, it’s the people skills that have been the source of the most professional growth.
When I joined the Django project, it was still a young project, but it wasn’t my project. It’s become clear that the tone and direction of the project’s early days had a profound effect on the development of Django as a whole—and, in many cases, contributed to its success.
With BeeWare, I’ve had leadership responsibilities from the start, so the onus is on me to set that direction. Being put into a position where I have to actively consider the sort of culture that I want to develop has forced me to think long and hard about those subjects—and has caused me to consider my own leadership and communication style along the way.
Dealing with the differences between what you want, and what the community wants. If you’re writing code just for yourself, you can do whatever you want to do. Try something new. Introduce backwards incompatible changes without hesitation. Spend time going down a rabbit hole exploring an interesting idea.
As soon as you take on maintaining a project, you’re asking other people to invest in your ideas: which, ironically, means that your own ideas sometimes need to take a back seat. If they don’t, you run the risk of people walking away from your project because you’re not being responsive to their needs.
Making matters worse, sometimes these “requests” aren’t expressed in especially polite tones, either. So the added challenge is to maintain empathy for the needs of your community, when some members of the community don’t do themselves or their cause any favours.
“As soon as you take on maintaining a project, you’re asking other people to invest in your ideas: which, ironically, means that your own ideas sometimes need to take a back seat.”
My favourite all time FOSS contribution moment comes from my work with the Django project.
During the Sprint day of DjangoCon Europe 2011, I met a couple from Poland. It was their first time sprinting, so I walked them through the process of identifying an issue to work on, and how to go from there to a patch. I left them to their work, and continued around the room.
A few hours later, I ended up back at their table, and asked what they were working on, and if they needed any help. They showed me the bug they picked: one of the nastiest, hairiest bugs, deeply embedded in the internals of the relational algebra of Django’s database layer. Without wanting to scare them off, I indicated that they might want to start a little easier, but if they want to have a swing at something like that, they were more than welcome.
A day later, they told me that they had a patch ready. It was such a complex patch that I told them I wasn’t going to be able to merge it straight away. I didn’t get a chance to take a look until several months later, at the PyCon AU sprints. And, despite one or two fairly minor problems, it was correct.
Two years later, this couple—Ola Sendecka and Tomek Paczkowski—came back into my life as the organizers of DjangoCon Europe. They had taken the enthusiasm with which they had tackled that database bug, and turned it into a major community contribution. They’ve continued to be involved in the organization of DjangoCon Europe. In 2015, Ola Sendecka (along with co-conspirator Ola Sitarska) went on to found DjangoGirls.
I love this story because it shows that one small act of friendship, like welcoming a contributor at a sprint, can have a profound impact. These two people, once empowered, have had an incredible impact on the Django community—and the entire world.
“One small act of friendship, like welcoming a contributor at a sprint, can have a profound impact.”
Right now, we need warm bodies of all kinds—coders, testers, documenters, translators, platform experts. Drivenby contributions are great, but most of all, we need people who are interested in sticking around for the medium-to-long term.
In FOSS projects, when someone new asks a question or wants to get involved, you know nothing about them. They might be someone who contributes one patch and moves on or they might be the next Ola Sendecka for your project. So you have to treat every contributor as the next big contributor. This is a repetitive and time-consuming process - and when someone that you’ve spent hours coaching to their first commit disappears, it can be really demoralising, too.
“Don’t ever forget that at the end of the day, coding is a social activity. It’s something that people do with other people, for other people.”
Despite the missives I sometimes get in my inbox, I believe that most people are, fundamentally, good. We may have very different views on what “good” means, and how to manifest that “good” in the world around us, but with very few exceptions, I don’t believe people wake up in the morning trying to be mean. However, the stresses of everyday life, the ambiguities of electronic communication, and differences in experience can lead people to leave bad impressions.
One of the principles that BeeWare team members are asked to follow is to assume people contacting the project have good intentions, and respond in kind. We don’t use this to excuse bad behavior, but to explain it—to recognise that we’re communicating with people, and people have bad days. Every interaction with another person is an opportunity to make a friend or foe of the project.
Of course, if someone is persistently rude, be they user or maintainer, they need to be shown the door. Still, Maintainers set the tone for their community; and ultimately, you get the type of contributors that you cultivate.
project
location
day job
From flexible hosting to data‐powered security, get everything your team needs to build at their best.
Contact sales