Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
We’re sharing interviews from several open source contributors about their projects, challenges, and what a GitHub sponsorship means to them. This week, read about Russ Magee.
With the launch of GitHub Sponsors, open source maintainers and developers can apply to receive funding from the community that depends on their work. Through sponsorship, open source maintainers have the freedom, financial security, and autonomy to continue the work they’re passionate about to further build and strengthen the open source community.
Over the next few weeks, we’re sharing the stories of several open source contributors. Learn about their projects, challenges, and what sponsorship means to them.
Dr. Russell Keith-Magee is the founder of the BeeWare Project, building GUI tools and libraries to support the development of Python software on desktop and mobile platforms. He is also a 13-year veteran of the Django core team, and was president of the Django Software Foundation for five years. He’s a frequent speaker at Python and Django conferences around the globe, sharing his experiences as a FLOSS developer, community maintainer, and startup founder. He lives in Whadjuk Noongar boodja—otherwise known as Perth, Western Australia.
BeeWare is a collection of tools and libraries for building cross-platform, 100 percent native GUI applications in Python. The goal of the project is to make it as easy for a Python developer to write an application for their phone, tablet, or desktop machine as it is to build and deploy a Django website, or get a Jupyter shell running to visualize some mathematical calculations.
I co-founded a web-based startup a few years ago, but soon after it became clear that we needed a native iOS and Android application to support activity on the website. Since we were bootstrapping, we didn’t have the resources to pay for two independent application implementations, so a cross-platform solution was essential. We ended up using a Javascript-based framework, but that meant duplicating lots of logic that already existed on the server-side, and the app itself ended up being little more than a mobile website wrapped in an application shell.
What I wanted to do was use Python to write a completely native application. And after some initial experimentation, I proved to myself that it was possible. I started building the tools and libraries to hide the complexities right away—BeeWare is the result of this work. The startup has since shut down, but my goal of enabling cross-platform app development in Python lives on.
One of the biggest challenges involve projects being able to get the resources they need, in the quantity they need, to address maintenance and strategic goals in a timely fashion.
Small bug fixes are relatively easy to resource. If you encounter a bug that is causing problems in production, it’s not too hard to convince your boss to let you spend a day working on a fix. But larger-scale work, like adding big new features or refactoring old codebases, is a lot harder to resource. Convincing a company to dedicate three months of engineering time to build a feature that can be used by competitors isn’t an easy task.
Then we get into the unglamorous day-to-day project management work like updating project websites or triaging bug reports. This is work that needs to be done, but doesn’t present any tangible benefits to the company that uses the project. As a result, this work tends to be done in a volunteer capacity, after hours and on weekends, even when the software is potentially being used by large organizations to generate millions in revenue.
This has a profound—and often unrecognized—effect on our community. It’s personally validating to be the maintainer of a project that you know is being used by companies big and small. But when the maintenance workload for a popular project falls on you as a volunteer, it’s very easy to get overwhelmed by the amount of work that needs to be done to keep the community happy—even though you don’t receive anything other than recognition and exposure for the work that’s done. On a purely technical level, this can mean critical pieces of community-maintained software don’t receive as much attention and maintenance as they require, resulting in bugs like Heartbleed. On a personal level, this leads to burnout and other mental health issues in our community.
It weakens our community in more subtle ways, too. If you rely on volunteers to do essential tasks, that limits who can get involved. Many people have other life responsibilities, such as family members that need regular care. Those people don’t have as much free time to volunteer. Unfortunately, these responsibilities often fall disproportionately on women and people of color due to social inequality, but opportunities for advancement in open source communities are generally only afforded to those who have a history of contributing. This perpetuates our industry’s skew towards young white men, who tend to not have these external responsibilities. And this weakens our industry, as the breadth of experience of those from other backgrounds isn’t brought to the development process.
Addressing resource issues provides a way to address all these problems. It means critical community management and maintenance work can be done in a timely fashion. It also means strategic research and development can be performed without having to prove the project’s importance to an individual company’s engineering budget. And it can potentially provide visible opportunities for advancement to people from underrepresented groups who are just as capable, but don’t have the personal resources to demonstrate that capability in a volunteer capacity.
Contributing to open source projects has been a transformational experience for me. It’s allowed me to practice communication and community organization skills on a scale that would be inconceivable working in an office in an isolated corner of the world. It’s introduced me to professionals with remarkable skills and knowledge and given me the opportunity to practice and hone my own technical skills in ways I couldn’t have imagined. It’s exposed me to people with an amazingly diverse range of life experiences, which has deepened my appreciation of empathy and compassion and how important both are in our everyday experience.
It’s also connected me with a worldwide community of the most wonderful nerds and geeks, many of who are now my dearest friends.
BeeWare is still a beta-level project. I describe it as a “compelling proof of concept”. The biggest contribution need right now is platform knowledge. Supporting six different native platforms (iOS, Android, Windows, macOS, Linux, and native Web) requires a lot of specialist knowledge, and each platform has a different skill requirement. I’ve learned a little bit about a lot of platforms to get BeeWare working. But progress has been much faster when I’ve been able to find contributors who know one platform really well.
I’d like to be able to recruit more contributors with specialist platform knowledge—but that doesn’t mean the knowledge has to be pre-existing. A contributor who is motivated to learn even though they don’t already have platform knowledge is just as valuable, especially if they’re willing to make a long-term commitment to supporting that platform.
The idea of collective pooling to achieve resource goals isn’t a new one. However, there are potential advantages to having that activity tightly integrated with the community. BeeWare has a website, but the first point of contact most people have with the project is through one of our GitHub pages. This makes GitHub a natural focal point for fundraising activities.
At the heart of open source resourcing problems is an underlying discrepancy between cost and value. In any open source contribution, the value extracted from that contribution is collectively extracted by everyone who uses the software. However, the cost of making those changes must be carried as an individual. My hope is that by surfacing funding behaviors and options in the GitHub UI, this will allow us to shift the cost of open source development to be carried collectively, establish a new set of community norms around resourcing open source projects, and as a result, make it much easier to get the resources needed to perform essential maintenance and strategic development.
I believe the work being done on the BeeWare project is critical for the Python community. The last 10 years have seen a massive shift in the devices people use for computing. Phones and tablets are achieving market penetration that laptops and servers have never achieved. My son started high school last year and his entire educational experience is being delivered through a tablet. But when he asks me if he can learn Python to use on his tablet, I don’t have an answer for him. Currently, there isn’t a good answer for how to build a tablet app in Python. Long term, this is an existential threat to Python as a language. Python is an incredibly popular language today, but if you can’t use Python to solve real problems on the platforms that people are using, why would people learn Python tomorrow?
I’m trying to address that gap with BeeWare. To date, my work on BeeWare has been almost entirely in my spare time. I’ve been fundraising for the BeeWare project for a couple of years on other platforms, and I’ve been able to use those contributions to pay for hosting, stickers, and Challenge Coins. However, I’m a long way from being able to earn a living wage from these contributions. If I can substantially increase the level of financial contributions from the community, I could consider making a more substantial time commitment to BeeWare development—potentially even working on it full time.
Want to learn more about featured maintainers? Read about:
Check back soon—we’ll be adding new interviews every week. Contact us If you have ideas about how GitHub Sponsors can better serve the open source community.
