Today, around 96% of software projects utilize open source in some way.
The benefits are endless: you get to build a community, get new insights on your code and even build your own brand as an individual.
However, being open source doesn’t end at releasing your source code; there are some crucial steps that often get overlooked in the area.
This episode includes:
Open source was originally coined in 1998 with the team building Netscape who wanted to release their work to the public. Since then, lots of communities and organizations were built around this idea.
The official definition of open source was created by the open source initiative. It consists of various points:
Currently, some large companies have adopted new licenses that don’t strictly adhere to the point about no discrimination against fields of endeavor. The Business Source License created by MariaDB is the most popular example, which was recently adopted by HashiCorp. Elastic, Redis and MongoDB have similar licenses, too - they hold every piece of the open source definition except that they prohibit building a competing service.
It doesn’t meet the strict definition of open source, but nowadays, the question arises: does that really matter?
You can still get the source code and use these tools for commercial purposes. You just can’t build a competitor to potentially take down the company that built these tools in the first place. This is an interesting dilemma in open source advocacy, and it may even shift or split current views.
Some people might want to adhere to the classic definition and insist that you cannot have any restrictions on your license. It’s understandable, because the original definition has been vital to spreading the use of open source software - currently, 96% of software projects utilize open source in some way.
On the other hand, some companies restrict building a competitor to keep their businesses sustainable, which is a reasonable need. They don’t want larger businesses to cripple them by bundling their services.
Both the strict and the more laidback definition of open source can be useful in the right setting, but finding the right balance between restrictions and free use can definitely be a challenge.
With the majority of software projects utilizing open source, it’s hard to imagine going back to proprietary software. Open source is a lot more convenient; if I need a certain functionality, I type in one command, and I have a library of it for free. Open source software also has the power of building a community: people release their own projects and contribute to the ecosystem of resources frequently.
Working on open source projects even helps you build your brand as a developer. On larger projects, there can be thousands of forks (new pieces of software created from the source code of another open source software). A lot of times, people will create a fork to add their own features or to contribute back. The author can then reach out to them about incorporating their work into the original software.
There’s a common misconception about contributing to open source projects. A lot of people will say that it’s just altruism; you’re expected to work on projects for free. However, that’s not entirely true.
By being active in the open source community, you’re building a public portfolio - even if you don’t work for prestigious companies like Google or Microsoft, you can contribute to their products, which improves your software engineer resume. As you build more, you’ll build an impressive library of contributions, which will help you stand out from the crowd in any job application.
There’s a belief that private software is more secure, but it’s highly debated. According to some, if we keep our source code to ourselves, it’s inherently more secure. I disagree. When the code is out there in public, it has more eyes on it. When someone uses your project and they spot a security flaw, they’re going to report it.
For example, there have been major security problems with the OpenSSL library, causing major problems across the internet. But at that time, the whole library was managed by one person. Since then, people have come to realize that it needs more people’s supervision to be sustainable.
As any security engineer would say, being closed source doesn’t make your software secure. You’re hiding your implementation details, hoping that nobody sees it, but there are probably things in there that are not secure. In case of open source software, lots of other developers could help you find these potential breaches.
The only way to be 100% secure is to practice proactive security, and to embrace radical transparency instead of following the “security through obscurity” approach. Don’t hide your vulnerabilities - put them out there and be open to feedback.
I’ve seen some companies publish the source code of their software, thinking that’s all there is to being open source. In reality, there’s more work with it. You should also focus on community building and bringing in contributors. Then you have to manage the community you’ve built, because there will be some disagreements - in this case, you’ll need to take the lead on handling conflicts. You have to create and enforce some contribution guidelines or code of conduct. Building and fostering your community is essential to any open source project, regardless of its size.
Another important aspect that companies tend to neglect is having an expert in the field. In contrast, a lot of businesses now establish OSPOs - open source program offices. It’s run by open source experts who can build the whole program and guide the company through the whole journey, from releasing projects to setting up contribution guidelines.
There is a lot of help available to get started. I’d recommend the TODO Group, which stands for talk openly, develop openly. It’s a consortium of open source program offices from lots of companies throughout the world, and they offer all kinds of resources from documentation on how to start an OSPO to webinars.
I got started with open source using the Linux operating system when I was just a teenager. Back then, it was mind-blowing to realize that I don’t have to go to the store and buy a CD, I can just go on the internet and download an entire operating system to my computer for free. Not only that, I can also talk to the authors, ask questions and report bugs. I can even try to fix things myself. It was incredible.
It was also a great learning opportunity to see this whole ecosystem of software available - this is what got me into software engineering in the first place. My personal growth has also been somewhat connected to open source’s growth. There have been challenges and hurdles along the way, but I learned that all I have to do is show up. Use a piece of open source software, report bugs and feature requests, and help each other out.
Our core products are built on open source. They had to be - being open source enabled us to move quickly as a startup. If we built everything from scratch, it would have taken us decades. We haven’t released our core products, because they’re specific to our business. Nobody would want to work on that in an open source setting.
We’ve released some other open source projects instead - the ones we think others would find useful. One of them is called Vulnbot that we use for tracking our software vulnerabilities. It calls into existing vulnerability management systems, gathers everything that is detected in our software, and reports it to individual teams owning these projects internally. This is 100% open source and could potentially be useful to other people at other companies.
Joey has been working in software engineering for over 20 years. He’s passionate about open source software and brews beer in his free time, which he finds similar to working with software as both require a process of creating something out of nothing.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀