Dave Stokes has just written that MySQL is Looking for
External Contributions. The first comments on that were
negative, saying that forcing developers to sign a contributor
agreement is not friendly, and that MySQL developers don't play
well with external contributors.
To be fair, it is not Oracle that has an unfriendly policy about
contributions. It was already like this with MySQL AB, and the
reason is simply that the company wants to maintain ownership of
the code, so that it will be able to sell dual licensing
agreements.
I may not like it, but licensing was still a consistent part of
the business when I left Oracle, and I assume it still is. Since
this “feature” helps paying the developers that create open
source software, I believe it is a reasonable trade-off.
Besides, also MontyProgram asks the same thing
(https://kb.askmonty.org/en/mca/), and so does Apache
(http://www.apache.org/licenses/icla.txt) and Canonical
(http://www.canonical.com/contributors).
It is a reasonable request. Not only it allows the main project
to retain ownership of the code, which is often a requirement to
trigger further revenues, but it also gives the project some
legal protection when the contributor submits code that was
created by others.
All in all, it’s a good thing that Oracle is encouraging
contributions!
About the MySQL developers not playing well with external
contributors, this is also nothing new. To my chagrin, when I was
working with MySQL I realized early on that not all developers
have a mindset that plays well with community participation. That
is just to be expected. I know brilliant developers who can
deliver exceptional code, but don't understand the concept of
coding in an open environment, or don't have the ability of
cooperating with other developers that are not colleagues. Is
that a bad thing? For someone, yes, but I don't think so. If the
final result is that the community gets great code for the effort
of non social-oriented developers, I still take it ans day "thank
you!"
As a community manager in MySQL, I tried to improve MySQL
attitude towards external contributors, but I had to acknowledge
that we could not force the developers to work against their
inclination. There were (and still are!) some developers who play
well with external contributors, but forcing everyone to work
with contributors outside the company may have endangered
productivity. The developers at MySQL were hired for their
technical skills, and with small exception the choice has proven
right, as there are developers capable of delivering first class
software, which is used in mission critical applications by
countless businesses.
So, there are proposals that are rejected by the developers. This
is a bad sign for the contributor, but a good sign for the users.
A rejected proposal means that someone took the time to examine
it, and balanced the options between accepting the contribution
and writing the same feature from scratch. Or even rejecting the
contribution because it is not worth it.
Let me clarify, because this point is not widely known. This
description refers to the process as I knew it 3 years ago. It
might be changed now, but I doubt it has changed for the
worse.
For a feature to get into MySQL code, by any developer, meaning
either an employee of MySQL or an external contributor, it must
pass three obstacles:
- There must be tests for the code provided. A feature that does not include tests, is rejected.
- The code must be reviewed by one or two senior developers. The first things that the developers notice is (besides having tests or not) if the code duplicates something that was already done. If it does, they suggest rewriting the code in such a way that it uses existing features rather than creating new ones.
- The code must pass the test suites in all platforms supported by MySQL. This is more easily said than done. External contributors test in their preferred operating system, and then they think they are done. But MySQL has a testing farm that submits every proposed commit to the full range of the operating systems that are actively supported. So chances are that a proposed contribution breaks the tests in one or two operating systems. At that point, the employees who have been reviewing the code can either ask the initial developer to change the code so that it is multi-platform friendly, or they can do it themselves. Having supervised many such exchanges between employees and external contributors, I know for a fact that the contribution is a hard task for both sides. Since MySQL has a policy for high quality (mandatory tests, code review, test passing in all platforms), every piece of code submitted to trunk is the result of a long process, which every would-be contributor must be aware of and willing to endure.
One more thing that comes to mind in this context. An additional
difficulty of contributing to MySQL is given by MySQL code being
quite intricate. It was initially created when resources were
scarce, and thus it includes design decisions that made sense 15
years ago, but could be written quite differently nowadays. The
Drizzle project exposed most of these issues, when it stripped
down most of the legacy code and implemented the database server
in a more agile way, at the same time making it easier for
contributors. But it did that at the expense of breaking
compatibility with the past. Since MySQL gets most of its
popularity by being already widely adopted and available,
breaking compatibility is not a path that the project wants to
walk now. I know that the developers are refactoring the code to
make it more modern and manageable, but they are doing that while
trying not to break anything that works well today. It's a slow
process, and someone may not like it. But it's a sign of
continuous progress, for which the community should be grateful.
As I am.