* Kyle Forster (kyle.forster@...) wrote:

-------
Transparency --

The over-arching concern that we (BSN folk) have tried to mitigate with
design and process proposals is a "tyranny of the committer majority"
problem in the controller project, a situation where a highly concentrated
group of committers blocks well intentioned progress by teams around them
whose applications call for different design trade-offs and timing
priorities.

This issue is very real in other well known SDN open source projects where
competing companies are regularly locked out from material commits. The
result is an awkward amalgamation of open and closed source components
across a handful of companies now, a trail of open source that isn't
broadly used in production and a lot of confusion.

The problem isn't because the concentrated group of committers in these
projects have been evil, or dumb, or mean. They simply prioritize designs
for the needs they see and add friction for the needs they don't until
those needs go away. While subjective, I submit to the list that the same
patterns are emerging in Daylight already, and it will take extraordinary
effort by motivated individuals in the months ahead to avoid this path.

This is a community effort. The whole premise of Opendaylight is
founded on that tenant. We have project lifecycle and charter language
to protect this. What you are identifying is a lack of trust.

Communities are _built_ on trust.

-------
Let's go to facts --

First, the D-E plan you linked to above does *not* specify a starting repo
in writing, but rather states explicitly on the page that the authors
disagree on this point, a point that has been re-emphasized in the public
threads. D-E plan, full steam ahead! Which D-E plan starting repo?

Second, on community support, by my count of emails on list, I came up with
10 organizations voicing support for a fresh repo / committer list and 3
against. Have we asked for on-list support from others who share our
concerns privately? Yes! But even if we filter by TSC organizations
(community+$$$), we came up with 3 in favor, 3 against, 3 no explicit vote.

Coming up w/ meaningful numbers here is difficult.

--------

How to move forward? --

We are in strong favor of the fresh repo and blank committer list with Dave
and Colin as the first two committers. Let them invite other committers to
the "merged controller repo" along with their code as it flows to their
design. This is the suggestion I believe that both Dave and Colin have
supported as their own compromise as the authors of the D-E plan.

It has the nice property of parallelizing work -- as we've drilled down,
there is a lot to do on SAL to make it ready for production-grade
Floodlight components, and a lot to do on making production-grade
Floodlight components SAL-ready. We're signed up for a lot there.

It has the nice property of aligning incentives -- committers are naturally
balanced across those who get implementations, not ppt, in shape for
Colin/Dave acceptance as quickly possible. We see this as healthy.

It has the nice property of reducing the "tyranny of the committer
majority" risk -- no community process or design is perfect, but we're
optimistic this approach will yield a positive outcome.

We're in support of the D-E 'fresh repo' suggestion for kick-starting the
D-E plan, we're quite motivated to make the controller project a balanced
committer repo and we're quite motivated to see this move forward. If
there is community consensus on this approach, great! If not, we look to
you (Dave) to figure out a decision protocol at the next TSC call.

The TSC does not own this decision. The community does.