At 10up we don’t just use open source software - we are deeply embedded in its philosophies and believe in our responsibility to actively support the foundation on which we build. We do this by way of contributing to existing projects and open sourcing our own.
This guide is written with groups releasing smaller-scale open source software in mind. The majority of our open source projects are narrowly-focused extensions to existing ecosystems, such as WordPress plugins or front-end components, and this set of best practices reflects that. There are a lot of lessons learned from managing large projects such as WordPress itself that influence our approach, but we recognize that (much like in client project management) different projects come with different needs and no single set of tools or methodologies can be universally applied.
Much of the web as we know it is built on top of open source software, some with the backing of companies, some subsisting on volunteer effort and other donations, and most somewhere in between. Think about the things we might commonly use when building and serving a website (this list does not constitute endorsements or preferences): NGINX, OpenSSL, MariaDB, PHP, WordPress, Node, React, VVV, Firefox, VS Code, Git. It’s hard to imagine today’s web without those technologies, and every single one of them is open source software.
Open source software is software where the source code is openly available so that you can use and modify it. (See the open source definition at the OSI). The common usage of “open source” doesn’t just refer to the availability of the source code but also the ethos and values associated with community ownership, collaboration, and permissive copyleft licensing.
As developers, we benefit by not being required to pay license fees for many of the tools and projects that enable us to make a living, so it’s important that we consider ourselves not just to be users but also active and engaged stewards. Open source software typically involves communities as a part of the open source ethos, but that doesn’t mean you have to immerse yourself in making changes to the software itself to be a supporter - sponsorship and contribution to software projects and their respective communities can come in many forms. In the PHP community, that could be sponsoring and speaking at conferences. In the WordPress world, that could be participating in WordCamps or releasing themes and plugins. In the Node universe, that could be opening a GitHub issue or releasing a package.
The short answer is that you can think of investment in open source as being a part of marketing and recruiting. It’s important not just because contributing gets you external visibility, but rather because of what that visibility truly represents: deep knowledge of the software you use, a commitment to making sure it stays viable and useful, effective asynchronous communication and project management especially for remote companies, and a declaration of your values as a company.
Potential clients feel confident that you know what you’re doing and can guide them through initial builds and beyond; current clients benefit from awareness of coming changes. Prospective employees have multiple points of entry and potential personal connections as members of an open source community; colleagues benefit from knowledge sharing and the chance to hone their skills through participation in open source.
Pushing some code up to GitHub and calling it a day may qualify as open source, but at the heart of this guide is the open process associated with effective open source stewardship. This is everything from being mindful about licensing to defining maintenance procedures to proactive communication with all participants. Please see the Maintenance Process section for more on how to approach open source software with an open process.
Please review our Contributing guidelines for details on the process for submitting pull requests to this guide.