From: Brandon Low <lostlogic_at_lostlogicx.com>
Date: Tue, 15 Jul 2008 08:04:27 -0700

Despite my long absence from active participation in this project, I'd
like to take a moment to voice my concern about this choice of
direction. I hadn't realized that this proposal was moving forward
until just last evening, or I would have spoken up sooner.

Rockbox has long been a technocracy, steered by the project founders and
the technical elite. In this condition, there has _always_ been tension
between the young and brash developers (I was one once) and the old and
stodgy developers. This natural tension is what has made the project
great over the several years that I've been aware of it. When a new
idea first hits the scene, it is most often rejected until a more
refined solution and one which allows the support for our binsize
limited targets to continue (albeit often at a reduced level of
support).

The only justification for this steering board is that it will help to
prevent "patch rot" on the tracker. I see absolutely no way that this
can be a good thing. If a patch rots on the tracker, then it is because
no developer with sufficient skill and karma takes it up and polishes it
to Rockbox inclusion standards. I've seen almost no patches of high
code quality ever rejected after being submitted by such a developer.
How can it possibly be considered a good thing to include less polished
patches into the repository? Rockbox has a level of code quality that
most projects can only dream of because of our/your long refusal to
accept inferior additions.

There is a reason that outside branches and patch collections are
maintained. They are the place where an idea can receive testing before
it is coded up to the standards of Rockbox. This is much the same as
the Linux Kernel development process and I see no reason for it to
change.

What I see is that a few highly politicized parties in the Rockbox
community want to have a way for the concerns of users to be taken into
greater account, rather than the technical concerns of developers being
the final and all-ruling master of the project. If you want to step
down this dark path, forever will it dominate this project. (Sorry,
couldn't resist.) There are plenty of projects that take this path, and
their development becomes mired in focus groups, endless debates in
committees, and <strike>elections</strike> popularity contests. Many of
these projects continue to make slow progressive development, but the
spark of true innovation is swallowed by the political burdens. Two
good examples of this are: Gentoo Linux (which I once developed for) and
GNOME. Once great innovators of the open source world, these projects
are now basically mainstays, everyone knows what to expect of them and
nobody expects great things. On the darker side, we have xfree86, which
eventually succumbed entirely to the political process and was entirely
supplanted by a new, more agile, more technocratic project called X.org;
and Debian which has become infamous for its slow pace of development as
a result of review boards and code by committee. On the technocrazy
side of the coin, we have the shining example of the Linux Kernel, which
remains as ever a project with a high bar for code entry, based almost
solely on technical merit and trust; it continues to have a high bar for
innovation and for code quality and at the core level does not have
steering boards, committees, elections or any other such nonsense.
Sure, there are user groups that control some of the spokes of the
development of Linux, but they cannot magically by vote cause something
they support to be passed up the chain, unless someone with sufficient
skill and code-karma picks it up and moves it up the chain toward Linus
and it has a high enough bar for quality and low enough for
invasiveness.

If some members of the Rockbox community want a steering board or any
such other political entity, let them create it outside of the core
development arena and steer the creation and submission of patches by
that outside group, but I urge you not to give any such board any power
over the final decision of inclusion or not inclusion. The natural
technical leaders of this project may not be as active as they would
like to be, but handing their naturally earned power over to an elected
board will only hasten any fall into irrelevance and mediocrity that
they may fear. Let new natural leaders arise in time and mentor them
toward that eventual position.

Thanks for reading, and I know this won't change anything at this late
stage in the game.

Sincerely,

Brandon Low
Received on 2008-07-15