The main reason why my conclusions are different from Gianugo's is the starting point for my reasoning: There is no inherent conflict of interest between participatory open source and pursuing for-profit business goals, so we must not create artificial obstacles for business wanting to develop Open Source software building upon an Architecture of Participation. Now, I can hear Gianugo objecting "But my entire blog entry and reasoning about why we need an impartial body and non-discrimination was about documenting the very existence of that inherent confict of interest". Well, read on, and let me start by underlining where I agree with Gianugo.
First, I agree with Gianugo in that he has identified the right passage in my previous blog where our reasoning differs:
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.
He argues that this documents that MySQL doesn't have a neutral point of view when accepting code contributions, and I agree this is coherent with the rest of his reasoning.
Second, I agree with Gianugo in that turning down a contribution for no good reason is an excellent way of demotivating a contributor. If I know my contribution is technically highly merited, usable for many, and thus expect it to be included as part of the body code, I will get very upset if it is rejected for apparently no good reason. I won't contribute again, and I will share my anger not just with my friends, but with the general public. Others will likely also be discouraged from contributing. This undermines the Architecture of Participation, and any good community vibrations will asymptotically approach zero degrees Kelvin.
While this seems as total agreement between Gianugo and Kaj, how can we then arrive at different conclusions?
Let me describe a scenario where I think it should be legitimate for MySQL to reject a technically valid contribution on commercial grounds, and why I don't see it as an inhibitor for creating a vibrant community. I can even make the case fairly generic.
Basic assumption: MySQL has created a for-money-only, commercial offering, which constitutes a compelling reason for some customers to buy something from MySQL AB. This offering is of interest to MySQL users and differentiates our free offering from our business offering. It is the "something more" you get for entering a business relationship with MySQL, where you spend money to save time, instead of spending time to save money. The fact that our revenues are greater than zero is proof that there must be some offering from MySQL that our customers consider meaningful on top of what we offer at no cost to our community. Not all of these revenues are services billed by the hour of MySQL employee time spent. Some services are even based upon the delivery of software, such as the MySQL Network Monitoring and Advisory Service. Let's use the term "the little difference" for what MySQL offers the paying customers beyond what we offer the community of users who use MySQL at no cost.
Now, should you have a contribution that renders the little difference useless, don't expect MySQL to be happy about adopting it.
If Gianugo now says, "See, Kaj, that's my point. If there is not a neutral body governing contributions, then progress is hampered by self-interest. So there cannot be true Open Development, and there won't be a vibrant community.", then I disagree at least with the second part of his reasoning, and my ambition is for MySQL AB through its deeds to prove beyond doubt that one can create an Architecture of Participation around Open Source software, while pursuing for-profit interest, even preparing for an IPO. I MySQL can fulfil the ten requirements I listed yesterday
- 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;
then I think we will have created a vibrant community of contributing developers.
So what happened with the upset contributor mentioned earlier, whose well-merited contribution was turned down because it undermines our business offering, and who told all of his friends about his negative experience, and who blogged for everyone to see about why he won't ever contribute again, and loudly proclaims nobody else should, either? Well, I think that won't happen, and I've actually already communicated why, in the little sentence "Now, should you have a contribution that renders the little difference useless, don't expect MySQL to be happy about adopting it."
While most of the interests of the community of MySQL users are very well aligned with those of MySQL AB the company, there is a small subset which is not. Expect us to happily adopt nearly any technically merited contributions that make MySQL more powerful, easy and efficient to use. Don't expect us to adopt contributions that eliminate or fully undermine the compelling reason to buy our commercial offering.
The virtual Gianugo sitting opposite me now objects: "So why would I as a contributor know, or even be interested in, what you consider to be your business interest, and what will undermine it?". I hear him, I understand his question, I think it is a valid one, and I even have an answer. You don't know our business interest. You would merely need to accept that there is a legitimate interest for MySQL to earn money on something, and the rest is taken care of by the contribution process itself. That contribution process has feedback loops between contributors and MySQL to give answers to contributors to the question "Is MySQL interested in adopting my contribution?", before so much time is spent by the contributor that the answer "I'm sorry, no" will render him or her furious. Remember, the virtual Gianugo sitting opposite me accepts that there are technical reasons why we might see us forced to answer "I'm sorry, we cannot enter your contribution into the code base at this point in time." -- the code might not conform to our coding standards, it might be in conflict with another feature we're just inserting, it might make MySQL too slow, it might not work with Replication, etc. etc. And if I, as a contributor, have spent huge amounts of time on a contribution, expecting it to be accepted into the codebase, I will indeed be furious, no matter what the reason for non-acceptance is. If I have an idea for a contribution that is deemed unacceptable by MySQL AB for commercial reasons, but it's turned down by MySQL while I haven't still spent loads of time on it in the belief that MySQL will adopt it, I will be disappointed, but I'm not going to lead a rebellion.
So this is why the yet-to-be-published acceptance criteria for code patches (item 6 in my ten requirements) will also include commercial aspects. This is why the "well-defined public guidelines for how to participate in the development process" (item 2 in my ten requirements) will state that there must be frequent enough feedback loops between the contributor and the non-neutral body managing MySQL, i.e. MySQL AB, to ensure that a contribution being developed is on track towards acecptance in the code, on both technical and business grounds.
My firm belief is thus that the Architecture of Participation is compatible with commercial interests. Non-neutral owners of Open Source code bases who strive for profit can, legitimately and without a bad conscience, exclude certain contributions on commercial grounds. And they can still establish vibrant contributing communities, by not setting false expectations. I think there is a sufficient number of developers who are willing to contribute code to such projects, because of the many common interests, including the expansion of the world of Free Software.