On my last count, there are now 20+ Sun Contributor Agreement (SCA) signatories whose names appear on the master list and who are interested in contributing to MySQL. Only this week, three new members signed the SCA.
These 22+ signatories have all been added since mid-February when we launched the new, Sun-compliant SCA signing process. Before the end of 2009, if we proceed at this same rate, MySQL SCA signatories list should grow to about 70 to 90 contributors.
In the meantime, contributions from many of these contributors have already been accepted and integrated. (I had earlier pointed to Armin Schöffmann's contribution as a simple example of how all this works.)
Some people continue to wonder why an SCA is required.
First of all, it is important to note that by signing the SCA the contributor retains copyrights while also granting those rights to
Sun as the project sponsor. This granting is very specific to a particular code base and the community around it. (This is a code base that has been available under GPL.)
Second, as I have summarized, in a series of Golden Rules for Open Source Contribution-Based Communities, several important rules for such communities help it to operate well. As part of rule G, "Setting Expectations," I did mention how
2. Anticipating the future and related risk management helps all market participants to reduce transaction costs.
However, I failed to add that an important ingredient in that risk management is the management of ownership claims.
I believe this particular aspect of rule G, which is implicit there, and which perhaps needs to be made more explicit, explains clearly why something like an SCA is required in order to maintain a flow of contributions to MySQL in a form that allows clear code ownership.
Note that other open-source communities, such as the Apache Software Foundation, also require their own contributor agreement. Often, these agreements are there to protect the maintainers of the project/product or the general integrity of the products' ownership.
BSD-based communities seem to avoid this need by posting various clear signs in various places -- in their member-initiation or commit e-mails -- that all contributions are made under BSD. However, these communities have remained somewhat fragmented due to the greater openness of BSD licenses. Don't get me wrong. I love BSD. Note that often, BSD contriutors would rather contribute to a BSD project. The whole objective of contributing to a BSD project is that you are building a based that can be used by anyone for open and closed business with that same base. This is very unique to BSD type or Apache type licenses and forms one of the main reasons contributors contribute to these projects.
So, let's now go beyond the question of SCA and see what else is going on.
The update and simplification of SCA submission process for MySQL, came along with equally important simplification of forge pages for contributors and with an effort to speed up the review of contributions and continuting with greater openness in MySQL development processes. [These apparently fragmented but hopefully useful (and ultimately coherent) steps have all been part of a larger initiative to facilitate openness, community participation and contributions. Again, please refer to the Golden Rules. Hopefully, you can faciliate and help the MySQL community to get more open and vibrant as an open-source community.]
It is important to note, here, that roots of this initiative go back to some years earlier. So, the initiative is related in part to a continuing series of efforts to make MySQL more open and more contributor friendly, including the famous "quality contribution program," which was originally launched by the MySQL community team. (In a sensem the "quality contribution program" has evolved into this simpler, more robust model and many of the lessons learned there have also been applied and used here.)
Under the SCA, contributors can contribute to all MySQL open-source products in open forums and issue tracking "systems"-- internals list, bug tracking system, worklog system. I put quotes around "systems" because there's more to be done to make these systmes work better together in a more open environment. Note that the MySQL team prefers to receive code contributions and bug fixes through the first two modes because those two modes (i.e., bugs db issue tracking and the internals mailing list) better afford two-way communications. Note, too, that contributions can be at the level of bug fixes or features.
Why would anyone contribute?
Well, there's a great deal of challenge to contribute anything to a software as sophisticated and complex as a database.
Besides the reputational effects, there's also this practical effect that once a contribution has been absorbed, the contributor will no longer have to worry about constant merges to get the effect he or she expects form MySQL.
Of course, there are many other reasons as well. For example, there are those who are just problem solvers, and find it exciting to contribute to MySQL. However, let me stop speculating on this any further. Instead, let me point you to an "internals" posting by Stefan Hinz, regarding a "MySQL University" session on replication features in 5.1 and 6.0.