MySQL, Open Source

Greg Stein Talk at EclipseCon

Greg Stein, chair of the Apache Software Foundation, and an employee at Google, working on open source projects, gave a very informative and compelling talk this morning comparing the various open source (and commercial) licensing schemes and the development model of both the Apache Foundation and the Eclipse Foundation.

Some of the main points of Greg’s talk were that:

  • The Apache Foundation manages a community, not code.
  • The trend towards commoditization in the software industry will push most software licenses towards non-copyleft licenses (more in a later post)
  • A community will grow only when it is given the freedom to grow, and part of this freedom is the ability to commit code to the project

As for Apache managing a community, and not code, Greg is saying, quite rightly, that the value of the Apache Software Foundation is not in the combined quality of the project’s code, but in the robustness and range of its community members. He urged that, despite long-standing commercial associations with companies like Sybase, IBM, Actuate, and more, that the Eclipse Foundation finds its strength in similar roots: the openness and ubiquity of its community.

What struck me most about Greg’s talk on the Apache Foundation and licensing models is Greg’s uncanny ability to put current issues aside and focus on the long-term trends and viability of the open source community and development model. I would not be surprised if this alone is the reason he was elected chariman of the ASF.

I had a chance to chat with Greg immediately after his talk and asked him what he thought MySQL could do to foster the kind of community interaction that Apache has had; whether he had ideas on how MySQL can structure community involvement in ways that would help our community grow. Despite his ideas on the GPL and its limiting factor on developers (the subject of another, later post to be sure), Greg mentioned that the community, in order to grow effectively and be “unleashed”, must be granted the full respect of the organization or project overseeing the evolution of the software, and be provided the ability to make changes to the software freely, to tackle its weaknesses, and to expand the software’s strengths through plugins, addons, and modular extensions.

This point hit home in a peculiar way for me. MySQL 5’s pluggable storage engine architecture (which Arjen will be giving an in-depth tutorial on at this year’s Users Conference), provides a (seemingly) ideal way for our community to influence and improve the MySQL server software in myriad ways. But, strangely, there has been little to no community reaction to this pluggable architecture — a fact that I have been struggling to explain the reasons behind. So far, I have come up with the following list of reasons why our community (yes, you… 🙂 ) have not been particularly active, or inclined to participate, in building pluggable storage engines for the server:

  1. The depth of knowledge needed to build such pluggable storage engines is fairly extensive
  2. Developers don’t “see the point”, if MySQL will control whether such code will be incorporated into the server
  3. The existing set of storage engines adequately fills all niches for which most usage is required.
  4. There aren’t enough tutorials or documentation from MySQL to begin such a project

Of these above reasons, I fear that #2 may be at work. Is it? Does the fact that MySQL is an open source company, but developed internally, with no public committers to the core work, limit the success of a pluggable architecture as nifty as MySQL 5’s storage engine architecture? Or is it simply that developing these plugins is too difficult for most of the MYSQL community — certainly an understandable answer.

You may be wondering what all this has to do with Greg Stein’s talk… Well, the issue of our community adopting the tools that MySQL has provided to enable community contributions &emdash; namely, the pluggable storage engine architecture — goes to the core of Greg’s argument that a community will only grow when given the ability to grow. In other words, have we, MySQL, given the community a tool that the community is unwilling to use because of issues related to our internal development model? Will future pluggable architectures built in to the MySQL server — for instance, a pluggable monitoring architecture or the ability to create modular stored procedure parsers for a variety of languages — be met with the same lackluster community involvement?

I want to know the answers to these questions, because they address the fundamental health of our community, and answers to these questions will help us identify those areas where we can structure things to ensure our community is happy, healthy, and willing to tackle code contributions towards the community server.

As always, very eager to hear your comments. If I’ve made any errors, either in my remembrance of Greg’s talk, or in judgment of our community, they are, of course, entirely my own 🙂