Discover more from Mostly Python
Toward sustainable development practices in open source
MP 62: An insightful initiative to bring new contributors to an established project.
Open source projects that have been around for a decade or more have usually addressed some of the limitations that come from having one primary leader, or a small group of leaders that hold control of the project. But no open project is completely self-sustaining. It always takes work on the part of current maintainers and project leaders to keep a healthy, balanced community of contributors.
Django is one of the most mature projects in the Python ecosystem. The first release was made in 2005! A number of critical decisions have been made along the way that supported the project’s longevity, and ongoing relevance. Those decisions have been both technical and community-oriented, often a mix of the two. There's an important new initiative that’s being developed along these lines in the Django community, called Djangonaut Space.
While clearly focused on Django, I believe this initiative has potential to inspire similar efforts in other communities as well. In this post I’ll share a bit about how I’ve seen similar longevity issues play out in another volunteer community I’ve been part of. Then I’ll share some of the reasons I think the Djangonaut Space program can help address these issues in the Django community, and possibly serve as a model or inspiration for other communities facing these challenges as well.
The generational problem in volunteer communities
Communities and projects that rely on volunteers have a generational problem: when the founding members are ready to move on, they need to pass on control and responsibility to a new generation. Generation in this sense isn’t always about age. More specifically, it means handing responsibility off to people who weren’t around when the community got started.
I was involved in mountain rescue work for twenty years, and I saw this same issue play out in many rescue groups. Many mountain rescue teams got their start as small, tight-knit groups of local climbers offering help to people in their area. Over the years rescue techniques were refined, and training became more formal. But leadership and control often remained in the hands of those early team founders. This isn't always a bad thing; familiarity with an area and knowledge of previous incidents goes a long way toward making complicated missions a success.
But there's a limit to how long one person, or one group, can retain control. I like thinking about mountain rescue communities around this issue because some of the challenges that come up are a little clearer in that realm. At some point, people are no longer able to climb the same peaks they did when they were younger. If they can still get there, they aren't able to do the extra work of rescuing someone from those high places. Sometimes this kind of change happens gradually, and sometimes you suddenly find yourself no longer able to carry out the missions you once contributed to with ease.
It's helpful to realize that people don't have to drop out of mountain rescue work just because they can't run up mountains anymore. There are all kinds of ways experienced people can continue to contribute. People with deep knowledge of an area are really helpful at helping plan missions, and evaluating the progress of a mission as new information comes in. Everyone can contribute in a variety of ways throughout their lives.
I've seen some teams make intentional efforts to pass on aspects of their team's leadership to newer members, long before any issues arise. These teams thrive as their original members move on from rescue work, and it’s a really satisfying thing to see. Other teams aren’t able to address these issues, and it becomes a real struggle to maintain an effective response capability. This isn’t always due to lack of effort or intention; managing volunteer communities with a difficult mission is impacted by many internal and external factors.1
Django's (latest) initiative
The Django community has been passing on leadership opportunities to new people for many years now. That said, it can still be difficult for people who are new to the community to figure out how to start contributing. The Djangonaut Space project has been in development for just under a year, and I’m really excited about how it approaches the issue of bringing new people into the community in an impactful and sustainable way. The core goal of the project is to connect people who are interested in contributing to Django with people who have already contributed, in a structured way that supports longevity.
Here's a brief rundown of how it works:
It's a cohort model, with specific roles for each person in the cohort.
Djangonauts are people looking to make their first contributions to Django, who would like some structured support in doing so.
Navigators are experienced Django contributors, who are paired with three or four Djangonauts.
Captains offer an additional level of support to Djangonauts, and check in with Navigators as well.
Each iteration of the program runs for eight weeks.
Navigators and Captains are there to help newer people, well, navigate the open source landscape. While they're free to teach specific things they have expertise in, their main job is to point people in the right direction. That could mean sharing some learning resources, or just clarifying how routine tasks are done in the Django community. The goal is to keep people from dropping out of the community due to the kinds of little things that are easy to address when you know the right people, but not obvious to people outside the community.
Strengths (and transferability) of this model
There are many strengths of the model that Djangonaut Space is developing. I wasn't sure what to make of it when I first heard about it, because all I really heard were the names of the different roles. But when I read the project's written description, most questions I had going in were quickly answered. A project that anticipates questions and potential pitfalls is much more likely to succeed.
Here are some of the strengths of this model, that make me excited to see it continue to develop:
It's explicitly welcoming. Many leaders of volunteer communities want more participation and contributions, but never figure out how to clearly communicate that message outside their own group. Making this message clear to people outside of the existing contributor group is critical.
It has explicit goals. One of the main goals is that participants will make specific contributions to the Django project, and the Django community. This is a measurable goal, which can be assessed through two questions:
Were you able to make a contribution to Django?
Do you feel equipped to continue making contributions to the project and the community?
There are implicit goals. Projects like this will always have some goals that can't be easily measured. The project aims to build connections within the community. It's difficult to measure progress toward a goal like that, but it's also well worth stating this kind of goal.
There's an explicit focus on not causing anyone burnout. Open source contributors are already giving a lot of themselves; how can we ask for more? There are structures built into this project that aim to keep people from burning out. For example, there's a weekly 30-minute meeting between Djangonauts and Navigators, but every Navigator isn't required to attend every meeting. Someone needs to be present to answer questions and hear people's experiences, but everyone doesn't need to be present all the time.
There's a clear path for growth. One of the problems of a cohort model is that if you're not in the cohort, you don't benefit from the program. While this project is in its pilot phase, that limitation is certainly real. However, the model itself is replicable. If it works, multiple cohorts can go on at the same time, with staggered start dates.
I spoke with one of the organizers, and they asked if I was considering being a Navigator. I said I really should bring my own project to completion before taking on that role. They then asked if I wanted help on that project. “Well, yes,” I thought, “I definitely want people to help out on my Django-focused project.” I found myself thinking too narrowly about what "contributing to Django" means. If it matches participants' goals, contributing to a third-party Django project is a completely valid basis for being a Navigator.
Once again, I was struck by how carefully all of this is being thought through. I haven’t ever felt like anyone involved in this project was trying to convince me to participate. Instead, the focus has been on explaining the project clearly, and inviting participation.
I don't think every open project needs an exact copy of this initiative. I do think, however, that it highlights some important questions for people to ask about the projects and communities they care most about:
When people new to our community want to contribute, how easily can they do so?
Who are our community's contributors? Do we have a steady stream of new contributors? Do they stick around and become long-term contributors?
What specific structures do we have in place to help existing contributors connect with people who want to contribute?
Are there key people doing work that's not being shared by others? If these people can no longer do that work for any reason, is there a structure in place to have someone else pick up those roles?
Every open source project doesn't need a long-term sustainability plan. It's perfectly appropriate for individuals and small groups to carry a project forward based on their vision, inside knowledge, and ambition. When a project or community runs up against the generational leadership issue, however, these questions become critically important if the project is to live on in a meaningful way. I believe the Djangonaut Space project contributes significantly toward addressing these questions in the Django community, and quite possibly for other communities as well.
To learn more about the Djangonaut Space program, check out any of these links:
The project’s home page.
A description of the overall program.
If you’re interested in participating, applications are currently being accepted for an 8-week cohort that starts January 15, 2024. If you’re interested in helping out in any capacity, you can fill out an interest form.
If you're a mountain rescue volunteer, please know that I'm not thinking of any specific teams as I write this. This dynamic has played out in one way or another on every team that’s been around for more than a couple decades.