Open-source projects come in all different shapes and sizes. Some projects have just the project creator and maintainer, while other projects have thousands of developers. Additionally, some projects are independently managed and other projects are backed by large organizations. While open-source projects are meant to promote innovation, how each project goes about it will be different. 

“For one, smaller, independent projects don’t need sophisticated workflows or community management practices at the onset, and often, that premature optimization can stifle community growth. We think of project growth through a ‘community maturity model.’ Projects should often wait to establish formal or documented processes as they mature, and not before they need them,” said Ben Balter, senior product manager of community and safety at GitHub. 

RELATED CONTENT:
The realities of running an open-source community
The ethical side of open source

Balter explained individual developers prototyping a new library don’t need a code of conduct or forms for bug reports, however once the first outside pull request has been established, the individual developer might want to start looking deeper at their documentation and start to formalize contribution and review processes to get ready for additional contributors. 

“That’s not necessarily true for organization-backed open-source projects that can either anticipate the success of a project or have teams dedicated to establishing cross-project practices,” he explained, “If you’re Facebook or Google and you’re starting an open-source project, it may make sense to include a standardized code of conduct or contributing guidelines for all your projects on day one to start things off on the right foot and set yourself up for success as the project grows.”

Open-source projects also differ with the willingness to invest in community infrastructure, according to Balter. For instance, it may not make sense for an individual developer maintaining an open-source project to provide technical support, but an organization-backed project with lots of developers can easily add new channels and categories that foster community engagement. 

Additionally, Balter suggested corporate-backed open-source projects be an internal developer advocate. “If your corporate lawyers are asking each developer to print, sign, and fax an agreement before they can contribute, it’s unlikely your project will gain many contributors. Similarly, if you can showcase contributors in your corporate communication, appreciation goes a long way when it comes to open source,” he said.