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
