We've recently detailed our policy and commitment to open source. We need to think in the interests of the project, while tending to the realities of running a business to support it. I wanted to share some of our thoughts around the decisions behind the policy.
<!-- more -->
## The challenge of being an open source steward
On Opensource.com, Matthias Stürmer identified [Four types of open source communities](http://opensource.com/business/13/6/four-types-organizational-structures-within-open-source-communities)
- single vendor open source projects
- development communities
- user communities
- open source competence centers
We could think of the last three types as marked by distributed development. Sometimes they are managed by community-organized foundations or associations but they have no singular point of commercial support. Examples include Apache, Rails and Linux.
The first type, “single vendor open source projects” are marked by support from a distinct commercial entity which mainly controls the direction and development of the project and financially supports a majority of core developers. Examples of this type of project include Wordpress and Automattic; Hadoop and Cloudera; or Elasticsearch and Elastic.
Every time you have a company in control of an open source project, people will have questions about how they’ll behave. The supporting company must balance the practical needs of running the business, supporting the development, and keeping the lights on. The company has to generate revenue, and the community and software project are reliant on the company to sustain. However, compared to closed-source or proprietary software, being open source ensures that the project can be forked and live even beyond the company.
## For us, open source is an ethos not just a license
Open Source arose from the Free Software movement. In the late 90s [when the term ‘open source’ was devised](https://en.wikipedia.org/wiki/Open_source#The_emergence_of_the_.22open_source.22_term), it helped to emphasize the fact that the code was view-able or modifiable. The term open source also downplayed the idea that the software was “free as in beer” which denoted poor-quality. At the same time the term laid the groundwork for commercial ventures to support these kinds of projects. Since 1998 open source has become a defacto standard, a mark of quality, and an assurance against vendor-lock-in.
However, the term open source has somewhat muted the activist origins of the free software movement: “free as in freedom.” When commercial companies supporting open source projects disregard these ethical issues it will serve to erode trust, which is essential for open source to work. Open Source is more than just a license, it’s also an ethos and commitment. Now, we have encoded our commitment. We have detailed our policy on being a good steward for the open source project.
## What does it mean to be a good open source steward?
I was hesitant to create a policy until we were sure about the circumstances and context for our project and company. Now that we have a few years of experience - we know better what is required.
We need to think in the interests of the project, while tending to the realities of running a business to support it.
We’ve outlined our commitment by looking at other communities and projects which have struggled with these issues. Typical criticisms of open source companies include:
- The governance of projects
- Transparent decision making about the direction of the project
- Company involvement in or support of open communication channels
- Putting the company’s interests before the project.
We had to think in terms of what was in the interests of the open source project.
We also looked at what it takes to sell a product and service. Our experienced sales team have helped us understand their struggles. They ask “Why do I have users who are running with over 10,000 developers who are not paying us a dime?” Artificial limits possible with proprietary services give salespeople leverage. They have asked “Can’t we have some limit, if you have over 1000 dev that you need the enterprise edition?” This does make sense from a sales point of view, but it doesn’t make sense in the open source context.
Open source is not a freemium model we can just turn off after 30 days. We can’t say “The first one is free!” It’s all free. Forever.
We can’t just tend to the needs of the open source project without tending to the commercial requirements. Afterall, we know that to sustain the project, we need to make it commercially viable.
We’re not the only ones dealing with these issues. “We’ve played with various mixes of what features go in to which offering, with how to balance our need to thrive as a commercial business with our core belief that Open Source is the future of infrastructure,” [wrote Adam Jacob of Chef](https://www.chef.io/blog/2014/09/08/there-is-one-chef-server-and-it-is-open-source/) That was one year ago, and now Chef has a clear governance policy and board of governance.
Each single vendor open source project needs to negotiate these issues.
## What is our policy?
We’ve focused on all of the things we have promised we won’t do. With this policy published, people will be able to hold us accountable.
