| title | Adoption of Open Source Principles |
|---|---|
| weight | 30 |
Nearly all software engineers use open source software, and most use open source software on a daily basis.
Research from Harvard Business School shows that the value of open source software in the global market is around $8.8 trillion – that is, businesses would have to spend nearly $9 trillion to create and maintain software internally if open source software did not exist. Businesses would have to spend 3.5 times more on engineering if it were not for open source software.
Open source software is ubiquitous in modern software engineering. Most programming languages are open source, and there are certain parts of the technical stack – libraries, for example – that are nearly always open source. If you think your organization doesn't use open source, you're almost certainly wrong. If you use Docker containers, you're using open source; if you use Go or Java or Python, you use open source.
The fact that using open source software makes engineering teams more productive is not controversial – it amounts to downloading software components and using them for free. But engineering departments can also become more involved in open source communities by contributing back to projects they use regularly and/or publishing their own open source projects. In most engineering departments, using open source software is simply the water that everyone is swimming in. Engineers don't think much about downloading and using open source software because it is so integrated into their workflow.
While the productivity gains from using open source software are obvious, there are risks to open source software, particularly to an approach to using open source by the rest of the business that either doesn't acknowledge that open source is used or treats it as purely an engineering issue. Without external guidance, many engineers don't know or don't think to verify the software bill of materials (SBOM) for open source components they use. Engineers are not lawyers, and not all open source licenses are identical. Absent a clearly defined open source policy, companies can find themselves in violation of open source licences simply because their engineers don't know which licenses are acceptable.
As individual engineers and engineering departments in general become more involved in open source, however, there can be additional questions that arise. An engineer who fixes a bug or writes a custom extension for a project he or she uses, for example, has to decide whether or not to contribute that work back to the project. There are obvious reasons for contributing that work back to the project; among other things is that doing so means that others can use the bug fix / custom extension or other functionality themselves, and then use the additional time they save to develop some other extension or fix some other bug. In other words, the entire ecosystem benefits.
However, not all organizations allow engineers to contribute their bug fixes or other work back to open source projects. In fact, in most cases it isn't clear to engineers whether or not they are allowed, which in some ways is even worse. The lack of a clear policy as to when an engineer can and can not contribute their work back to the community can have a chilling effect on the organization's ability to interact with the open source ecosystem.
The relatively low percentage of companies that have a formal open source strategy shows that the majority of businesses, particularly those who are outside of the software industry, see how open source impacts not just the engineering department, but the rest of the business as well.
The engineering productivity benefits that come from using open source software benefit the entire business, of course. They mean that software projects are finished faster, with a lower headcount, than would otherwise be possible. For any company that creates software of any kind internally, this has obvious benefits.
Whether or not open source plays an active role in the larger business, outside of simple productivity gains in the engineering department, depends on whether or not the company has an open source strategy. If they do not, and the company's engineers are primarily users, rather than contributors and/or publishers, in the open source community, they're not likely to get much else. However, open source can become a competitive advantage for companies, including those who are not strictly 'software' companies, if they know how to engage with open source communities and exploit the potential benefits from open source.
There are multiple ways that companies can engage with open source. The most basic way is by using open source; nearly all companies that develop software are users of open source software. In some categories, like software libraries and even programming languages, it's nearly impossible to avoid open source. But a company can also become actively involved in open source projects, and can also publish and maintain projects as well. The business benefits from each type of engagement are different, as are the roles that open source will end up playing in the business.
Open source is everywhere in software engineering, and your engineers are using open source software whether you like it or not. As a user of open source software, the main business benefit you'll accrue are from increasing the productivity of your engineering department. For a business audience, the most important takeaway is that using open source is not really optional; completely avoiding open source would put a company at a massive disadvantage compared to their peers.
While most people think primarily about code contributions when they think about contributing to open source software, for the purpose of this guide the definition is broader: If you're more than an anonymous user – you ask questions, you answer questions, you participate in activities around the project – you're a contributor.
Given the thousands of open source projects an organization is likely to integrate into their stack, not to mention open source applications they might use, even outside of the engineering department, it's impossible to get involved in all of them. For the majority of the open source projects you use, you will be an anonymous user. That is how the open source ecosystem is supposed to work.
But some projects are going to be more important for your company's success than others. In these situations, it can make sense, from an engineering and business perspective, to get involved in the project. The reason you do this isn't to "give back," it's because it is in your company's best interest. When a project is important for the company, getting involved in the project both creates business value and also mitigates risk.
There are many ways to become involved in an open source project. Simply asking questions in the community has value; it tells the rest of the community and the maintainers where people are having trouble and points to potential improvements in both user experience and documentation. Answering questions, helping with design, writing website copy, writing blog posts about the project on your own company website, contributing code, sponsoring foundations, sponsoring conferences, organizing meetups – these are all ways that you can contribute as an organization to a project's success.
While there are advantages to each type of contribution, the core value proposition is the same: you are helping ensure that the project continues to exist, and you are building a relationship with the community. Building the relationship with the community means that if you need something in the future – a bug fixed quickly, a new feature added – your voice is more likely to be listened to. Multiplied throughout the ecosystem, it means that others in the community are able to work together and your force is multiplied.
What about taking software that you've developed internally, and publishing that software under an open source license? What about investing in continual maintenance of that open source software that can now be used by your competitors?
This is the type of relationship with the open source community that most business leaders find hard to understand. Instead of taking something for free, your company is spending money in the form of engineering resources and then providing the result to others for free. Even your competitors can use the end result! Why would anyone do this?
Not all software you develop internally is a good fit for being published as an open source project, but some of it is. If a project doesn't directly give your company a competitive advantage, it might be a good fit for publishing as an open source project.
(Existing placeholder from main - to be developed)
- Definitions
- Implementation strategies for business-driven
- Connecting the two perspectives for a holistic approach