There is no question that open source is the backbone of software today. Mike Milinkovich, executive director of the Eclipse Foundation, explained that about 80% of all software written is open-source software. The benefits of using open-source software is immeasurable, but it’s not the code itself that makes open-source software an invaluable resource. 

According to Ben Balter, senior product manager of community and safety at GitHub, software and technology is the easy part. The hard part is creating and fostering a culture around an open-source project.

RELATED CONTENT: Creating and maintaining trust with open source software

“The superficial promise of open source is that if you publish your code, others will make it better. Strictly speaking, that’s not the case. To reap the benefits of open source, maintainers must seek to grow communities around their project, a step often overlooked when ‘publishing’ code,” Balter wrote in a blog post. 

Open-source project creators and maintainers take on a difficult role when they decide to release an open-source project. Balter told SD Times that maintainers should think of themselves as managers rather than engineers. Their primary contribution to the project often won’t be in the form of code, but in terms of community management, marketing, recruitment, evangelism, automation, tooling and support. 

“You often start a project to solve a specific technical problem, but as the community grows, in order to scale your own efforts and to have the biggest impact on your project, your role often shifts to solving the human and the workflow side of open source, rather than the technical,” said Balter.

What it takes to run an open-source project
GitHub’s Balter explained that open-source creators and maintainers should think of projects as a distributed dinner party. “Just as you would at a dinner party, as the host, you want to welcome guests as they arrive, take their coat, offer them refreshments, and introduce them to other party goers to ensure they have a good time. Open source is no different, except instead of taking coats or offering hour d’oeuvres you’re offering documentation and your responsiveness,” he said.

When starting a project or releasing code into open source, software owners should think about the developer experience of their project much like developers think about the user experience of an application, according to Balter. 

“How can you make it easier for developers to contribute? This includes documentation, setting up their local environment, writing tests, and following style guides to get their code included in the project,” he said. 

Once you have a plan or process set, the next step is to let developers know you want them to contribute. “There are a lot of projects on GitHub that might just be published source code, so distinguish your project from the others by letting potential contributors know that you’re looking to start an open-source project and welcome their contributions,” Balter explained.

In addition, project creators and maintainers should be open and welcoming to new contributors. It is helpful to take the extra time to welcome developers to the community and thank them for their contribution, Balter explained. 

According to Eclipse’s Milinkovich, part of the secret sauce at the Eclipse Foundation is that it has an open collaboration model that allows some of the largest companies in the world to work together with individual developers who are just interested in the technology. “Our ability to weave together contributions from many different people and organizations and in many cases direct competitors into something that delivers great value to the industry is definitely part of our success,” said Milinkovich

The project should also be sustainable. Milinkovich explained that even though open-source software is free to use, there is still a risk for organizations adopting open-source technology because if a piece of software is not sustainable in the long term, the users will be forced to switch up their application. 

“There is real business value in enterprises putting their logo to a project or community to say yes we are using this stuff, it is very important to us. We really want to help support its sustainability and in addition to that, if they actually put some developers in to participate then that is actually a better path to sustainability,” Milinkovich said. 

Once project adoption and contribution starts to pick up, it is important to focus on changes, Milinkovich explained. “Let’s say you built some great software, you are getting a lot of attention and you are suddenly getting an influx of contributions… you really have to focus on making the path to contribution as easy as possible. Maybe this started out as a one-person project, but now you want to start taking some of these contributions and turning them into committers and maintainers so you can grow the team a little bit.”

Mike McQuaid, software engineer at GitHub and open-source project Homebrew maintainer, explained most maintainers start out as a contributor and user, and should continue to be a user “to maintain context, passion and empathy.”

If a project gets very widespread adoption, or commercial adoption, project owners now have to think in terms of the stakeholders as well as the consumers. Each person is going to have different concerns about the provisioning of the code, licensing, support and maintenance.

Balter explained the definition of stakeholders should be continually expanded and include non-technical, non-users, potential users, veteran users, subject matter experts, technical users, active developers and potential developers. 

“Think about an in-person community you’re part of. It could be the neighborhood or town you live in, the congregation at your place of worship, or your local bowling league. Communities are about groups of people coming together to solve a shared challenge (having a nice place to live, practicing one’s beliefs, or socializing). Each community has its leaders (elected officials, clergy, team captains) and some form of codified ideals (legal code, religious teachings, league regulations). When you move that community online, the social norms that build a sense of comradeship also follow,” he said.

Overcoming the challenges: 
It’s not only about maintaining good relationships with developers and providing an open space to collaborate. Project creators and maintainers also have a number of different challenges they will have to deal with on a daily basis. 

Scarce resources. Starting a project or open-source community can be hard, especially when you don’t have backing from a company or organization, so resources are limited. Eclipse’s Milinkovich believes users should focus on a couple of areas where the project shows energy and forward motion. In terms of prioritization, projects and features should be grouped together into programs. “At the Eclipse Foundation, we always start from the projects. There are other open-source organizations that start off with consortia and press releases and marketing efforts, but we always start the other way. We work hard to recruit interesting and innovative projects and then we work hard to help make them successful, including recruiting companies that are participating in them and/or making sufficient investments in their own organizations, relying upon them that they want to help make sure that the project is sustainable,” said Milinkovich.

Security: Security will always be an issue in open-source software, so it is important to have a repeatable build process where you can demonstrate that the code being delivered is derived from the code being published, according to Milinkovich. “People want to ensure they are getting the real thing when they are downloading code,” he said. In addition, project maintainers should follow up with patches to make sure users are getting the latest and greatest stuff.

Burnout. It can be a challenge for developers to keep up with the demands of the community when they are responsible for maintaining code, moving the platform forward, keeping up with the release cycle and dealing with feedback constantly, according to Milinkovich.

To avoid burnout, GitHub’s Balter suggested to keep the community informed, set expectations, take a break or find someone to help. “You may find that finding ways to monetize your efforts through sponsorships, premium features, or support may help you to find that spark once again,” he said. 

The bus factor: “How many developers need to win the lottery tomorrow (or tragically get hit by a bus) for the project to fail? If it’s just you, that number is one. As a project grows and matures, you want that number to be as high as possible. Humans get sick or take vacations or get locked out of their account and a project shouldn’t grind to a halt as a result. It can be hard to know when a project goes from ‘my’ project to a community project, but as early as possible, move the project to a dedicated organization and empower contributors you trust to take on additional responsibility,” said Balter.  

Attracting and retaining talent: “Just as you might think of a sales funnel in terms of marketing to potential customers, engaging prospects, etc., the idea is to convert users to contributors and contributors to maintainers by lowering the activation energy required at each phase and thus growing your project by attracting and nurturing users, contributors, and eventually fellow maintainers,” said Balter.