81 lines
4.8 KiB
ReStructuredText
81 lines
4.8 KiB
ReStructuredText
============
|
||
Introduction
|
||
============
|
||
|
||
Where do the Four Opens originate from? They came from a need to do things
|
||
differently.
|
||
|
||
Free software started in the 80’s by defining four (initially three)
|
||
freedoms [#fourfreedoms]_ that any free software should grant its
|
||
users. Freedom
|
||
0 was the freedom to run the program as you wish, for any purpose. Freedom 1
|
||
was the freedom to study how the program works, and change it so it does your
|
||
computing as you wish. Freedom 2 was the freedom to redistribute copies so you
|
||
can help your neighbor. Freedom 3 was the freedom to distribute copies of your
|
||
modified versions to others. Those freedoms made you free to improve the
|
||
program, and release your improvements to the public, so that the whole
|
||
community benefits. But free software did not mandate anything about how the
|
||
software was to be built to actually encourage this collaboration across
|
||
boundaries that would result in benefiting the whole community.
|
||
|
||
When open source was defined in 1998, it focused on a specific angle (the one
|
||
that mattered the most to businesses), which is the availability and
|
||
re-usability of the code. That also said remarkably little about how the
|
||
software should be built, and nothing about who really controls it. As a result
|
||
by 2010 most open source projects were actually closed one way or another:
|
||
their core development may be done behind closed walls, or their governance may
|
||
be locked down to ensure control by its main sponsor. Sure, their end product
|
||
was licensed under an open source license, but those were not really community
|
||
projects anymore.
|
||
|
||
The control of a specific party over the code is discouraging contributors to
|
||
participate: those are seen as free labor and are not on a level playing field
|
||
compared to contributors "on the inside", which really decide the direction of
|
||
the software. The only option for a disgruntled community is to do a costly
|
||
fork of the project, and fragment the limited resources available to work on
|
||
that topic. The most extreme case is the open core variant, where a company
|
||
maintains the basic functions of the software as an open source "community"
|
||
project but keeps advanced "enterprise" features under proprietary licenses.
|
||
This inevitably creates tension when a user wants to contribute back an
|
||
improvement (like security or scalability) that the controlling entity would
|
||
prefer to keep for its Enterprise edition. All this control ultimately hurts
|
||
the adoption and the success of the software.
|
||
|
||
OpenStack was started with the belief that a community of equals, working
|
||
together in an open collaboration, would produce better software, more aligned
|
||
to the needs of its users and more largely adopted. It was therefore started
|
||
from day 0 as an open collaboration willing to include as many individuals and
|
||
organizations as possible, on a level playing field, with everyone involved in
|
||
designing the solution. This was relatively novel: while a few venerable
|
||
projects like the Linux kernel were set up and perdured as truly open
|
||
collaborations, most new projects in 2010 were just owned by a "main sponsor"
|
||
This is why it was pretty important for us to state in a very concise way what
|
||
we really meant by Open. It was also important to clearly distinguish ourselves
|
||
from prevalent open core solutions like Eucalyptus, which was then the only
|
||
open source cloud infrastructure platform available.
|
||
|
||
It was from these conditions that "The Four Opens" were born. The first public
|
||
mention of them was posted on the then-nascent OpenStack Wiki on June 28,
|
||
2010 [#fouropenswiki]_, before OpenStack was even publicly discussed or
|
||
announced. The titles of the Four Opens (Open source, Open Design, Open
|
||
Development, Open Community) were set from that day. The content evolved a bit
|
||
over time on the Wiki, as implementation details rolled in (for example: public
|
||
code reviews, design summits, technical committee, lazy and consensus). The
|
||
Four Opens description is now maintained officially in the OpenStack governance
|
||
web-site [#fouropens]_.
|
||
|
||
After eight years, the Four Opens proved pretty resilient, consistently
|
||
managing to capture the "OpenStack Way" of doing upstream open source
|
||
development. Under their rule, the OpenStack community grew from tens of
|
||
contributors to thousands. They were instrumental in the success, the quality
|
||
and the visibility of the OpenStack software. As this book will show, they also
|
||
proved applicable to downstream activities such as user feedback gathering,
|
||
marketing, or event management. As the OpenStack Foundation turns to more
|
||
generally support Open Infrastructure, the Four Opens will grow beyond
|
||
OpenStack. Let's apply them to other nascent open source projects with the same
|
||
success.
|
||
|
||
.. [#fourfreedoms] https://www.gnu.org/philosophy/free-sw.en.html
|
||
.. [#fouropenswiki] https://wiki.openstack.org/w/index.php?title=Open&oldid=9628
|
||
.. [#fouropens] https://governance.openstack.org/tc/reference/opens.html
|