On Wed, 05 Aug 2009 10:21:38 +0100 Mark Shuttleworth <mark@ubuntu.com> wrote: > Hi folks Hi there > We're already seeing a growing trend towards cadence in free software, > which I think is a wonderful move. Here, we are talking about > elevating that to something that the world has never seen in > proprietary software (and never will) - an entire industry > collaborating. Collaboration is the primary tool we have in our > battle with proprietary software, we should take the opportunities > that present themselves to make that collaboration easier and more > effective. Truly an enthusiastic speech which gives us a vision of a bright new world and even includes the yes we can spirit. And yet I lack the trust that such will ever happen. To convince so many and so diverse groups to all commit to a single goal, and may it just be something as profane as a common freeze date, would be unprecedented in human history. But let's assume I'm wrong, and it is actually going to happen ... > Well, the first thing is to agree on the idea of a predictable > cadence. Although the big threads on this list are a little > heartbreaking for me to watch, I'm glad that there hasn't been a lot > of upset at the idea of a cadence in Debian so much as *which* > cadence. We can solve the latter, we couldn't solve the former. So > I'm happy at least at that :-) I'm sorry then to rain on your parade. Despite the risk of being accused of heresy, let me state my doubts about such a move in general. I leave discussions about specific advantages or disadvantages that this might hold for Debian to others, much more competent on the matter. Instead I would like to approach this issue more abstractly. We know of many examples in nature, human society, economics, computing, etc., that show that distributed, non-hierarchical, self-organising system can be much more powerful than centrally controlled systems. It can be proved, for instance, that a swarm of independent units without central control can converge a solution in cases, where classical iterative schemes that have such a central control do not[0]. Add central control (a central clock) and this power vanishes. While it is not clear if such a model applies to the FLOSS world without doing extensive research, I strongly believe that it would harm the system if you add a central control (in this case some central committee that decides on freeze dates). While it might look appealing at first sight to have a central authority to decide on certain matters, this rips the system of the ability to change quickly and adapt to new circumstances. But let's again assume that I'm wrong and that it would do the FLOSS world good. But: good how? What exactly will be better? It is an ambitious goal you propose which will require projects to make compromises, to invest time and possibly money, to change their priorities. So at the end of the day people will want to know if it was worth the investment. What are the criteria on which this question can be decided? That, say, GNOME releases in time for the distributions to pick it up is easily testable, but not an advantage on its own. That the world becomes a better place is a worthwhile goal but impossible to verify. Would you please give verifiable and falsifiable criteria which can be evaluated objectively to answer such a question? Examples would be - the "productive" work/bug fixing ration increases - less security leaks - number of people moving to GNU/Linux per year increase - etc. At the moment it is not clear for me, what the real advantage for projects and users would be. However, I completely agree that collaboration helps everybody. But instead of inserting an additional level in the hierarchy to govern such collaborations, I believe the better approach is to tighten the collaboration-network. Here collaboration happens on a different level. Between package maintainers and their upstream, between projects that depend on each other, between Debian package maintainers and Ubuntu package maintainers, etc. Cheers, harry [0] Gerardo Beni: Order by Disordered Action in Swarms.
Attachment:
signature.asc
Description: PGP signature