(more difficult, could mean having a preferential lane) a neutral party such as a foundation owning the code.

I think Gianugo and Susan are pursuing a worthy cause in defining a software development model that doesn't just release software based on an Open Source license, but also builds upon an architecture of participation. However, for reasons I don't understand, they have included requirements that practically exclude companies like MySQL AB from ever fulfilling them. I am referring to requirements 4 and 5, and partly also 2. I argue those requirements are unnecessary: Open Development is possible even in commercial, for-profit companies.

In order not to steal or redefine Gianugo's term, let me thus propose another term "Participatory Open Source", with the following "first stab" requirements:

software released under an Open Source license;

well-defined public guidelines for how to participate in the development process;

a publicly available detailed list of bugs;

a public roadmap with detailed descriptions of planned tasks;

code reviews accessible for the public;

public code acceptance criteria;

active public instant messaging between the developers;

well-maintained public system documentation;

a publicly documented mentoring system for grooming new developers;

a worldwide geographic spread of the developers;

In some respects, this is similar to Gianugo's requirements. My 1 = his 1. My 2 = his 3. With his 2 and 3, he may also refer to some of my items 3 to 10, that are on a more detailed and practical level, attempting at describing the baseline components of an Architecture of Participation in software development.

In other respects, there are clear distinctions between Gianugo's set of five, and my set of ten. Most of all, my set of ten would work for a company with a commercial agenda (like MySQL AB), whereas Gianugo's items 4 and 5 would not. I think it is absolutely possible to combine a commercial agenda with an Architecture of Participation when developing software, and not just in producing or distributing content (like, say, Google or Amazon). That is why I have excluded any requirements like Gianugo's 4 and 5 from my list.

On a specific, detailed level, I also see a need for clarification in Gianugo's item 2 "a non-discriminatory access to the developerÃ¢â‚¬â„¢s community".

First, what is "non-discriminatory"? If non-discriminatory means "code contributions shall be accepted regardless of the gender, race, country of origin, or age of the contributor", it's probably OK (whereby certain countries of origin might incur exposure to legal or other risk). If non-discriminatory means "even technically inferior contributions must be accepted", it's obviously not OK. The interesting middle ground is whether it's OK to say "no" or "maybe later" to technically sound contributions that don't fit with the business interest of the owner of the main code base. I would argue that such "discrimination" is OK, as the "Participatory Open Source" requirements would otherwise impose so severe purity limitations, as not to be interesting for companies with a commercial agenda, like MySQL AB.

Second, what does "access" mean? The right to participate? Sure. The same rights as the central governing body? No way.

Finally, what is "the developer's community"? OK, this may only need a phrasing clarification, as I suspect Gianugo does refer to the community of people developing the software itself (in our case, those who code MySQL using C or C++), as opposed to the community of people developing code using the software (in our case, those who use MySQL when coding in PHP, Perl, Java, Ruby, Delphi, VB, Python, etc. etc.).

At any rate, I fully agree with Gianugo that there is more to Open Source than an Open Source software license: The active participation of the community in developing the software.

Oh, and finally: I don't think MySQL AB is yet fulfilling all ten points. But if I can have my way, we will when the year 2007 is over.