Over the last 20 years, we have seen the proliferation of open source software and technologies become part of commercial offerings, either as part of the technology stack that powers the product or part of the product itself. Although these two use cases are largely different, both have come to showcase just how useful open source is, not only for the developer community but for businesses as well.
One of the benefits of working with open source technologies or projects is the free sharing of ideas. Open source brings people together to brainstorm and develop a common piece of technology. The shared love for what they do crosses cultural and geographical boundaries. One of the best-known – and arguably, most important – open source projects is the Linux kernel and operating system. Linus Torvalds released the first version of the kernel to the open source community through a mailing list, sparking worldwide collaborative development and widespread adoption.
The passion for open source stems from a deeply rooted belief that contributors are solving an important problem, and that they are working towards the betterment of the world as a whole. In many cases, this is demonstrable. The Linux kernel now powers the majority of data centers worldwide, serving billions of users. But it’s not only that subjective passion that has played a key role in establishing open source technologies. The peer-review process of open source projects means that each code commit passes a rigorous, public audit and verification process. It has proven to be a superb way to increase code quality, reduce bugs and regressions and guard against vulnerabilities. Research has shown, objectively, that this process produces higher quality software than the standard, proprietary quality assurance and testing procedures.
When selecting an open source technology to use in development, there are a couple of issues that need to be considered in order to safeguard the quality of your product. One key consideration is to resist chasing the latest technology fad. Instead, select the right technology for the job. It’s in developers’ DNA to obsess over new and exciting technologies, but this does not always mean that they are appropriate. While Kubernetes may be the right solution if you need to serve millions of users at Netflix-like scale while managing maintenance and cost, it likely isn’t the best choice for a new startup launching the first iteration of their product. In this case, speed of development and flexibility to make changes is more important than scalability (so, perhaps, the startup might be better off using Ruby on Rails or Django). These three projects all share an important characteristic: They have active communities that not only safeguard project features but also maintain them and offer peer-to-peer support.
When implementing a new feature with a particular technology, this supporting community is very important, since they can greatly accelerate the development of your product. These are people who love what they do and want to see other community members succeed with the technology. In this regard, it’s also important to consider giving back to the projects and communities you benefit from. You can either participate in the communities and help others yourself, one-on-one, or contribute by sharing the improvements that you have made to the open source technology. If you have extended the API, for example, or discovered and fixed bugs, there is no reason not to contribute your changes back and further enrich the ecosystem. The credibility you build in this way can also be a benefit, as people will identify you, your team and your product as supporters of the open source project. It’s a virtuous cycle of collaboration with benefits that should not be underestimated.
As you and your product become an important part of the open source ecosystem, either because you use open source components or because the core of your product is open-sourced, remember that trust is notoriously hard to build and very easy to lose quickly.
Whatever one’s feelings are on this matter, the open source community is very careful about who they trust and can easily be alienated by a company that appears not to have their best interests in mind. In order to build trust, it’s important for teams to build credibility. Open source communities are largely merit-based, so unless the community sees proof of expertise and knowledge, they will not automatically trust a self-proclaimed expert. This credibility can even extend to the personal, like the many open source developers who have a large following on social media and lend their credibility to the projects and companies that they work for.
Finally, when dealing with open source technologies, projects, and communities, it’s key to remember that developers are very sensitive to blatant sales pitches. Authenticity matters in the way that a project, company or brand presents itself. Open source is all about collaboration and community; it’s a relationship built on trust and mutual benefit, not profit.
