Steps towards an open development process

[Norman Feske]

Hello everyone,

over the past four years, the Genode OS Framework has seen rapid
progress. Skimming over the release notes of the past releases makes me
very proud. It is clear that the project's development is going stronger
than ever. However, at the same time, I recognize that progress on a
technical level is only one part of a successful Open-Source project. A
certainly even more important part is the participation of a diverse
community. This is where our project is vastly underdeveloped. By
continuing the development at status quo, Genode will continue to
steadily improve but it will not be able to capture a significant
position in the operating-systems world. Instead, it will possibly
remain a curiosity. Therefore, we Genode developers regard the
transition of our work to an open and transparent development process as
the next big challenge we want to tackle.


Review of the situation

Even though Genode is an Open-Source project, its development has been
pursued largely behind the closed doors of our company Genode Labs. The
planning of the road map, most technical discussions, issue tracking,
and revision management were used to be done within the company. There
had been two reasons for this policy namely the preservation of
exclusivity and the efficiency of coordination.

Regarding the first reason, when we started our business, we desired to
preserve a certain degree of competitive advantage to ourselves by
keeping some information "protected" from the public eye. For example,
we thought that revealing the detailed history of the over 5000
source-code revisions of the project would enable any outsider or
competitor to deeply analyze the way of how our company works. These
concerns had been acknowledged by other startup companies with
statements in the line of "Open-Source has hurt our business".

The second reason is the way of how humans intuitively work together in
a non-distributed environment such as a our small company. Instead of
discussing technical matters on a mailing list, it appears to be much
easier and presumably more efficient to engage in face-to-face
conversations. The writeup of our releases notes at regular intervals
served us as an instrument to recapture the rationale behind our
discussions and document it. This worked exceedingly well. In
comparison, discussing every detail on a mailing list seems to be
inconvenient and long-winding.


Why do we desire a change?

The answer to this question can be put quite simply as "to make the
project relevant". But it goes deeper than that. First, we see ourself
as Free-Software AND Open-Source advocates. I wholeheartedly disagree
with statements that suggest that Open Source is incompatible with
having a business. For our company, the contrary is true. Without Free
and Open-Source Software, there would be no Genode Labs. The great
wealth of the GNU software stack forms the basis of all the tools we use
every day and it plays a significant role for our passion to develop
software. Furthermore, Genode would not be of much value without all the
great building blocks in the form of existing Open-Source code that we
reuse in our context. Hence, it is our personal desire to contribute to
the Free and Open-Source software world and to intensify the
collaboration with other projects in the same spirit.

We still see the preservation of a certain degree of exclusivity as
important for our dual-licensing business model. If we made Genode
available under the BSD license, there would be not point in pursuing
this model. However, hiding the development process from the public is
not only poor-spirited but it creates an artificial barrier for people
who want to participate. The book "Producing Open Source Software"
(http://producingoss.com) by Karl Fogel was an eye opener to us.

Regarding the efficiency of collaboration, I have to admit that the
statement above about how great the current way works is really not
well-founded - simply because we haven't tried the alternative to
discuss everything in public, yet. Obviously, we are risking to spoil
our presumed efficiency by changing the mode of collaboration. On the
other hand, by documenting the process of solving each problem in the
form of public mailing-list postings, we give everyone the chance to
contribute to and to learn from our findings. Reaching people outside of
Genode Labs is the only way to make our project relevant on a larger scale.


The next steps

We take the current release cycle as opportunity to execute our plan to
open the development process. Our coarse schedule is to migrate our
internal issue tracker to the public until mid of December. From this
day on, all issues will be tracked publicly. The place for all technical
discussions will be the Genode mailing list. Until mid of January, we
will prepare a new public source tree in the form of a Git repository
that we will then use as mainline development tree. There will be no
distinction between our development repository and the public repository
anymore.

As a further change of policy, we plan to include all documentation as
found on the website in the mainline repository and remove the Wiki.
This way, contributions to the documentation will be handled in the same
fashion as code contributions.


Hoping that our designated change is in the interest of all of you, I'm
looking forward to see how it will unfold and improve the further
progress of Genode.

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth