Why would you build an open source community? David Sommerseth, Team Lead of Core Development at OpenVPN, has his own war stories about his experiences as an open source developer and the important role of open source communities.
Sommerseth joined Red Hat in 2008, (“the definition of an open source company,” he said). He found it inspiring to work there. As part of his development efforts, he was working with OpenVPN. He needed some features it didn’t have, so he developed them. He sent the changes to OpenVPN and asked Red Hat if he could spend some of his time working on OpenVPN code. In 2016, Sommerseth joined OpenVPN as a developer.
A key player in the OpenVPN community, Sommerseth is the “gatekeeper” of changes to the OpenVPN codebase. Sommerseth reviews all code changes and is responsible for putting them out to others. The community slowly grew from two to three active participants to ten to fifteen regular contributors and another 30-40 occasional contributors.
Open source is not a business model; it’s a tool.
If you are a software company providing a specific set of features, then you don’t want to open source your code, says Sommerseth. But if your company can provide services around what you open source (e.g., integrations, enterprise features) that you can monetize, then an open source approach may work for your company.
Microsoft is one company Sommerseth reckons has taken a big step forward by open sourcing the core components of its .NET framework and building a community around it. Adobe is another, although not as far along the path as Microsoft.
A survey conducted by The New Stack and The Linux Foundation found that 63% of large companies (10,000 or more employees) are most likely to have an open source program.
An open-source approach works best when you have people passionate about the technology.
This is why Microsoft’s foray into open source makes sense. There are a lot of Microsoft developers passionate about .Net. Sommerseth describes it as an “itch.” Once you get started, you want to do more. And that makes it fun to contribute, he suggests:
A developer can get really involved with a project, the rewards being seeing their changes applied, and their name listed in the change log history.
Other ways community members are rewarded are through events and giveaways. Seldom is it monetary, according to Sommerseth.
Not always the company’s codebase
An important thing to remember about open source is that the code does not necessarily belong to the company. It could belong to an open source project. And with any open source project, everyone can copy it and develop it in a different direction (called forking). That being said, Sommerseth pointed out that forking is not the preferred or recommended approach.
Instead, the community gathers to decide if they like a change - and has the power to approve or reject any change. When you fully open source, the company developers no longer are in control of the direction of the project. They can steer it but not dictate it (which can be tricky, said Sommerseth).
In the same NewStack survey, it was noted:
Forty-four percent of companies with open source programs contribute code upstream, while the figure is about 6 percent for other companies. Upstream contributions to external projects are the best way to measure a company’s commitment to dealing with maintenance/efficiency costs and also an indicator of a healthy open source culture — a factor well worth considering when doing an analysis of the compound value that an open source office offers.
It’s not unusual that company developers come up with a change, and it’s not liked by the community. This slows the process because they have to go back and make changes. More eyes on the code and more feedback from community members can change the scope in ways a company doesn’t expect.
Typically, approval power comes from earning prior merits. As a new member or contributor gets positive feedback, and their changes are applied, they earn credit, eventually moving them into a position of reviewer or adding new changes.
Open source requires two-way trust
Two-way trust is required for open source to be successful. The vendor puts its trust in the community and vice versa. And when that trust fails, open source fails. This is when forks happen.
Consider the story of NextCloud and ownCloud. ownCloud was launched in 2010, NextCloud in 2016. Here’s what said its founder, Frank Karlitschek, said about his decision to leave ownCloud:
Without sharing too much, there are some moral questions popping up for me. Who owns the community? Who owns ownCloud itself? And what matters more, short term money or long term responsibility and growth? Is ownCloud just another company or do we also have to answer to the hundreds of volunteers who contribute and make it what it is today? These questions brought me to the very tough decisions: I have decided to leave my own company today. Yes, I handed in my resignation and will no longer work for ownCloud, Inc.
Karlitschek and many of the original members of ownCloud then started NextCloud, a fork of ownCloud. But where ownCloud had a community and enterprise edition, NextCloud is fully open source, getting its revenue from services. ownCloud is just one example of how you can handle conflict. In the end, Sommerseth notes, the best dea is to avoid a fork because it’s usually very bad for the original company.
Taking changes slowly and carefully
Speaking of his company, OpenVPN, Sommerseth says it doesn’t accept changes easily. This is likely due to it being a secure VPN, and it has to be careful about the changes made to the codebase. As community manager and gatekeeper of the codebase, Sommerseth often brings in others to help evaluate changes, leveraging their expertise in areas he isn’t as strong. As new changes are coming in faster than ever, he has others helping him ensure they are the right changes.
He's also working on a new Linux client, based on the 3rd generation of the OpenVPN code base. His work with the community focuses on the 2nd generation, and he is helping them move towards this 3rd generation, guiding the community to do the things the company needs (and sometimes vice versa).