So now that you have posted some clarifications on what is going on exactly, it seems like there is less of a problem as original thought. However I must say that the the replies you posted on Jeremy's blog (and later mine as well), you let me to believe that things are quite bad indeed. Only now that I see your two posts on /, I can relax a bit again. Matthew has written a very good summary of the situation with some historical background.
I guess its great that you take the time to post on the blogs of individual community members, but next time you might want to take a bit more care on what you post. For example in my post I explicitly asked to be corrected if I misunderstood what's going on. When you posted in my blog without correcting me, I assumed that I was right with my assessment of the situation. Also I am a bit concerned about how you compare MySQL's business model with PostgreSQL, because I think they do not really compare well (at least from a community perspective), though Josh predicted back when I posted my thesis paper on exactly this topic, that MySQL is moving towards the PostgreSQL eco systems "secret sauce" business model.
So where are we at? It seems that Sun/MySQL is considering close sourcing now yet developed code that provides implementations for plugins against some of the new pluggable API's. This reduces concerns since this way the chances of things diverging between the "real community" (more on this in the next paragraph) and Sun/MySQL internal development. More importantly it means that community users can easily load community developed alternative implementations without much hassle. I have not examined the plugin API's in detail, but from what I read they all loading of plugins without a restart. That being said its still likely that most hosters will not allow average users to load new modules, but I am not sure how that will play out and how much work there has been done to make it safe for hosters to allow this. So as long as the proprietary extensions focus around plugins against clearly defined plugin APIs, I see little problem from the perspective of the community. If this makes business sense is another story.
But there is still some concern that I have with Marten's comparisons made in regards to the PostgreSQL eco system. To me the key difference between their eco system and MySQL's is that MySQL does not have a true "community" version. MySQL AB and now Sun decides on what goes into the "Community Edition". More over its exactly the same company that also employ all of the key developers, so there isn't really someone outside of Sun/MySQL that could reasonably decide what should go in. Of course there could be community votes, but this is also not how open source works. For the most part the core group around an open source projects act like benevolent dictators that make decisions based on a mixture of personal needs and the goal to keep the project alive as open source.
There is this delicate trust balance that end users put into the lead developers of the open source products they use. For example look at all the complaints that Zend has gotten for having developed a closed source byte code cache. Ever since then people have said that this should be part of PHP itself, but Zend is stopping this from happening. Even today after years of having an open source solution available that is even run by Yahoo on their servers, we still do not have a PHP release with a bundled byte code cache. However Zeev has given his blessing to bundeling APC with PHP6. Is it Zend's fault that it took this long? Did Zend do enough for PHP that it was ok to give them this money making opportunity? However the key point is that the community "gave" Zend this opportunity, because there are enough non Zend people in the core development team. Again the situation is totally different at Sun/MySQL.
Maybe if Sun/MySQL would make it really transparent that its the MySQL developers that decide on what gets into the Community Edition with no influencing at all by managers, this could ensure that this trust balance is not thrown out of wack so easily in the future. If there would be a public promise that the community, and more importantly Sun/MySQL developers could fallback upon, it could a long way. So when there is an open source alternative implementation to a MySQL product, that someone is willing to contribute to the Community Edition (which will of course require that people grant MySQL the right to release the same code under a proprietary license - which in the sense is quite comparable to releasing code under the BSD license that PostgreSQL uses), and the code is good, then its the Sun/MySQL developers that decide what goes in and not the managers. Of course my assumption is that their decision will be based on love for the open source project they are working on and not the development of their stock options. Then again like I said earlier, open source developers always make their decisions at least partially out of selfish reasons and that is fine and dandy.
Thx for your comments. I am honoured that you seem to think that communication from me can be expected to be complete and correct, but it also worries me a little. When I write blog postings or other communication, I make the same mistakes as most people: I leave out pertinent facts, express something vaguely, miss a question that is being asked of me, and so on. I can only apologise if my first response on your blog didn't give the whole picture. Luckily you read my other blog postings where I perhaps expressed myself more clearly.
You ask about the comparison I made betweeen PostgreSQL and MySQL. I specifically compared the revenue generation aspects of the two products. When it comes to development model, there is a main difference. In the PostgreSQL community, product roadmap decisions are made by the contributors themselves. For MySQL, such decisions are made within a corporate context, i.e. by those employees who have been given this mandate. This applies, as you note, both to the Community and the Enterprise editions.
Both PostgreSQL and MySQL are eager to have active community engagement and contributions in the product development process. But at MySQL we believe it is useful that there is a unified place where the product roadmap is decided.
Which model is better? I don't think there is a conclusive answer to this. MySQL can claim that its model is better because MySQL has a much larger user base than PostgreSQL. MySQL also has many more customers and partners. PostgreSQL can claim that its model is better because it is highly appealing to contributors.
At MySQL we believe in our model because it keeps our resources focused on the same goal. And because we have set as our goal to not only serve customers but also to win more and more (non-paying) users, we also believe that we are good at sensing where we need to take the product from the perspective of developers and contributors. But these are judgment issues, and there are people who disagree with this. Even within our own organisation we can have fierce debates on this topic.
I appreciate your suggestion that "developers decide what goes in and not the managers". But in our organisation, we believe in our managers, and we ask them to make the decisions. Many managers are developers themselves, and all managers have a duty to listen attentively to their teams and take care of the well-being of their team members. This is why we probably would not change our model lightly. But we are always open to discussing the topic in the search for the perfect model. Our own current model is not perfect, but it works. If we can improve it, we will. If we at some point would conclude that we must make a 180 degree turn in this topic, we will do even that. But until such a point, we continue with the model and the plan we have.
It is my hope that you continue to express your opinions and suggestions to us. I appreciate it very much that you are taking the time to think about the best model for MySQL. This time I think we will not specifically follow your suggestion, but are listening carefully to it, and who knows what happens next time you suggest something. So thank you again for your thoughts!