[coreboot] Changes to the coreboot Project Structure

[Stefan Reinauer]

Changes to the coreboot Project Structure

We -- the coreboot project -- have succeeded beyond our wildest
expectations, with every major laptop vendor using our code. Going
forward, this will require a few structural changes that will ensure
that the vendors shipping coreboot products can count on a stable,
reliable code base.

With that incredible success, there is also a lot of work to be done to
make sure the project is scaling and keeping up with the requirements of
the millions of new users that coreboot gets every year. There is a
large number of new corporate entities investigating their possible
involvement in coreboot, and we need to make sure that their integration
is working smoothly while still keeping the project’s interests and
goals stable and alive.

Moving forward, we need to make sure that we can welcome these possible
new contributors without the friction that we have seen in the past.
The coreboot community currently consists of about 80 contributors with
varying levels of activity. Among these contributors, three groups can
be identified as the major stakeholders in the project: Sage Electronic
Engineering (the largest coreboot IBV), Secunet and Google Inc.
(delivering all new Chrome OS devices with coreboot based firmware).
Individuals employed by these three stakeholders make up for the
majority of code contributions. According to Ohloh, roughly half of the
coreboot contributions are done by the top ten contributors. Over the
project life time, over 80% of those have been made by corporate
contributors.

While there is a fairly good understanding of the project direction and
interest between those individual contributors, there are also an
increasing need for making sure that the coreboot project’s scalability
and its viability for mobile / consumer products and servers is
guaranteed. The goal of this proposal is to enable all of the community
to have a strong voice and make strong contributions to the project
while allowing the major stakeholders to steer the project direction and
pursue ownership of the components they provide.

Traditionally the development model of coreboot was very similar to the
model of the Linux kernel in many ways, including coding guidelines, the
requirement of a sign-off process for contributions, and active
leadership provided by a “benevolent dictator”. Commit rights were
traditionally given to few of the top contributors of the project.
With the introduction of git as coreboot’s version control system and
its multi-branch nature as well as gerrit for code reviews, the
landscape of the project has slightly shifted towards a more anocratic
development model in which different interest groups sometimes worked on
opposing strategies, and thus affecting the project’s overall stability
and suitability for large scale deployment negatively. The advent of
these new tools requires the original project founders and major
stakeholders to provide stronger leadership and strategic direction for
the project.

Measures to improve the coreboot Development Model

* Require authors to acknowledge changes made in their name (Forge-Author)
  This change allows contributors to decide when their OWN changes are
  ready for being integrated into the project, preventing unfinished and
  experimental work to be submitted accidentally.

  Status: ACTIVELY ENFORCED BY GERRIT

* Define owners for (sets of) mainboards and require these to act as
  maintainers / gatekeepers, being the controlling instance to submit
  these mainboard changes.
  Providing support for a new mainboard / chipset / component in coreboot
  is a major contribution that requires the contributors to invest dozens
  / hundreds / thousands of man hours. In the light of this we would like
  to give those who provide support for one of these components stronger
  ownership. The submitters of a component need to have the last word
  about what becomes part of their component and what does not. This will
  also give component providers a certain freedom of the actual
  implementation of the component, that might, in some rare cases, be
  different from the implementational structure of the framework and
  generic code.

  Status: TO BE ENFORCED BY POLICY

* Build a MAINTAINERS file for common code, and encourage people to keep
  subsystem maintainers in the loop for changes
  Aiming for top notch code quality, the coreboot project is generally
  trying to provide a solid and scalable framework for development as well
  as a number of generic cross-chipset components. Changes to these parts
  of the coreboot code affect a large number of supported systems. Hence
  it is important to have gatekeepers in place to guarantee they stay
  operational.

  Status: TO BE ENFORCED BY POLICY

* Look into making gerrit automatically add reviewers based on maintainer
  lists
  In order to streamline the code review process in a project that on
  average now has over 200 contributions per month, maintainers / owners /
  gatekeepers should be added to the list of code reviewers automatically.

  Status: TO BE INVESTIGATED

* Import previous code reviews and results
  The tree major stakeholders in the project all own internal code review
  systems, some of which are public (e.g. the Google Chrome OS repository)
  and have code reviews that include representatives outside of Google to
  ensure general code quality and making sure the improvements made for
  products don’t negatively impact upstreamability. For those cases it
  would be extremely helpful to honor the code reviews already done in the
  upstream repository

  Status: TO BE INVESTIGATED

* Significantly reduce number of submitters
  To ensure consistency, scalability and conformity with the general
  coreboot strategy, we need to define a clear committer structure that
  defines the original project structure of having a benevolent dictator
  aka project leader (Stefan Reinauer) and gatekeepers in place. The
  suggested structure will need to value both community interests and
  corporate interests equally and hence a good setup would be to have a
  final amount of six developers with submit rights, three community
  representatives and three corporate representatives (on from each major
  stakeholder):

  Current suggestions:

  Patrick Georgi (Secunet)
  Marc Jones (Sage)
  Stefan Reinauer (Google)

  Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the
  coreboot community)

  Status: TO BE IMPLEMENTED