This week, a combination of 6 inches of rain in 36 hours, 12 inches of existing snow, sudden 60-degree weather, and still-frozen ground created record-breaking floods in my city. (For those on the metric system, that’s 15.2 cm rain, 30.5 cm of snow, and 15.6 degrees C.)
Complicating this for me personally is that fact that I live one block away from a river which crested 7.2 feet (2.2 m) above flood stage late Wednesday night. The water is receding now, and our street is open for traffic again.
So, it’s been a fun week for the ducks, as you can see in the picture of the normally dry park across the street from my house. (The good news is for my family, the water coming in the basement is coming in at a rate a pump can keep up and it’s clean ground water. A worse flood in 2016 prompted us to pack everything up in plastic bins.)
Lately, the Open Source and Standards team has been called upon to help companies and commercial products with the process of improving the health of and existing open source project. Occasionally, we even get to help launch a new community that did not exist before.
Launching a new community is not exactly a cookie-cutter operation. Every software can have its own licensing and copyright issues that can keep the developers and the lawyers occupied for quite some time.
Beyond the code, focusing on the actual people that could help make a project thrive once it’s open, community managers need to spend time getting elements big and small ready to launch, too.
Open source projects survive off new contributions and new contributors, bringing new ideas and new focus to their work. A new project starts with one person or a few people putting code out for other people to use and contribute to, a successful project creates a pathway for contribution.
In Gluster, we’ve focused the past two years on making our infrastructure effective for contributing, and inviting more contributors into our infrastructure. Open source isn’t just about opening up your code—it’s about building a supporting infrastructure that invites people to contribute. For projects to be successful, the community needs to be able to participate in the governance, the documentation, the code, and even the hosting. Said another way, a healthy project can attract more diverse skillsets with more transparency.
Fedora is a community with a lot of moving parts and has at least five different ways of thinking about new contributor onboarding. Unlike some single code-base communities where there is a focus around a repository or a bug tracker, Fedora is constantly working on lots of things and the linkages can be hard to see. Some of those activities are directly (in a creation sense) related to the amazing Linux distribution we produce.
These activities, like Release Engineering, must happen or no bits get shipped. Other activities are critical to the experience of Fedora, like Design. Without these activities we might as well not ship. Some activities, like a lot of the work done by Fedora Infrastructure, are critical to providing the tools and glue we need to get our work done.
Onboarding is much on the mind of communities of late, thanks to Stormy Peters’ prompt on how community works at opensource.com. Go read it, as it inspired this post and will contain lots of great information in the roundup post later this week.
There is much—legitimate, mind you—celebration of late about the continued success of open source within software development. But there are times when that success may not be enough, even when good-faith efforts are made.
It is one thing to have an open source software project and quite another to have a healthy and growing open source community. Even when a company or project is making legitimate and strong efforts to free and open source processes and values, it may not always hit the mark—especially when it comes to community.
There are quite a few software projects that we in the Open Source and Standards group work with, both on personal and professional levels, and one of the key differentiators that gives a community better growth is the presence of what we call "onboarding."