Open source advocacy: The benefits of open source software (Interview with Joey Wilhelm, Security Engineer at Pinwheel)

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. 

Joey Wilhelm, Security Engineer at Pinwheel, talks about the benefits, security aspects and common mistakes of open source. 

This episode was written based on episode 81 of the Level-up Engineering podcast hosted by Karolina Toth.

This episode includes:

• Getting to know open source
• Strict definition
• Different approaches
• Free vs. restricted use
• Benefits of open source software
• Knowledge base
• Networking
• Portfolio building
• Open source vs. proprietary software from a security perspective
• Open source advocacy as a Security Engineer
• Common mistakes of releasing open source software
• Community building
• Experts
• Storytime: Becoming an open source advocate
• Open source at Pinwheel
• About Joey

What is open source software? 

Definition

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:

• Free redistribution and access to the source code are emphasized.
• Derived works and modifications are allowed.
• Integrity of the author’s source code is ensured.
• There is no discrimination against any person, group or fields of endeavor. 
• The license is redistributed with the code and isn’t specific to a product. 
• The license must restrict other software and must be technology-neutral.

Not ticking all the boxes

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. 

Free use vs. restrictions

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. 

How do the benefits of open source software differ from proprietary software?

Shared knowledge

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. 

Networking

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.

Building your own portfolio

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. 

Is proprietary software more secure than open source software?

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. 

Open source advocacy as a Security Engineer

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.

What are some of the mistakes that companies make when releasing open source software?

Community building

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. 

Experts

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. 

What’s your personal story on becoming an open source advocate?

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. 

What's the stance on open source software at your organization, Pinwheel?

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. 

About Joey

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. 

Check out Joey’s work on Github and on his website.