Sun Contributor Agreement and MySQL

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.


Most active contributors and prospectives have long given up on the internals list, for the simple reason that even getting a single response there proved to be futile.

If it is intended to be a public forum for this once more, that's great but will people actually respond when someone posts there?
Be very very sure before you answer yes... thanks.

Posted by Arjen Lentz on May 10, 2009 at 08:44 PM PDT #

I agree that the internals list is very quiet. However, all of my questions on it are answered quickly by core people (Sergei, Konstantin, Monty). Maybe we just need people to post more questions.

Posted by Mark Callaghan on May 10, 2009 at 11:00 PM PDT #

Arjen and Mark --

I've been monitoring the "internals" list informally.

In the meantime, we have also been encouraging participants in the MySQL engineering community to pay more attention to it and to make more effective use of it.

It seems the number of active e-mail threads (on "internals") have increased most recently.

Hopefully, this trend will continue in ways that will become more useful to the MySQL internals developer community.

We should all expect that responsibilities will be mutual on an open community list like "internals." Everyone will need to contribute what they can by way of technical answers, probing questions and examining the evolution of the MySQL internals' software. "Internals," at least as it stands today, is a common community asset that requires care and development by all.

In my opinion, "internals" should ideally be where we discuss various development issues, and potentially, the place that receives some automatically generated events related to various bzr development trees of interest (ideally, the main trunks, say 6.0, and 5.4), bug fixes, and some aggregate information like quality testing results, etc. -- very similar to Apache/Derby's derby-dev. Of course, Apache/Derby has the advantage that their internals development list (derby-dev) also receives issue tracking notification from a JIRA system, which they use to track all work, whether bug fixes or work on features. We have some disparate tooling in MySQL but we are working on better integration, while, in a sense, knowing about the role of the various tools is a rite of initiation in MySQL -- rites, of the like of which every open development community has some. Hopefully, we can make these rites of initiation even easier :-) ... These should be community wide tasks and objectives, in my view.

Posted by M. Mortazavi on May 11, 2009 at 01:06 AM PDT #

By the way, the MySQL Refactoring project was just launched ... ...

Posted by M. Mortazavi on May 12, 2009 at 08:35 AM PDT #

Post a Comment:
Comments are closed for this entry.



« September 2016