There's a story making the rounds this week about how Android isn't (gasp!) open.
This, despite the fact that the Android codebase is under the Apache 2.0 license:
"The preferred license for the Android Open Source Project is Apache 2.0. Apache 2.0 is a commercial and open source friendly open source license. The majority of the Android platform is licensed under the Apache 2.0 license. While the project will strive to adhere to the preferred license, there may be exceptions which will be handled on a case-by-case basis. For example, the Linux kernel patches are under the GPLv2 license with system exceptions, which can be found on kernel.org."
But in a analysis last month, mobile blogger Andreas Constantinou laid out a case that despite claiming to be open, Android is actually so tightly controlled by Google that the label of open source for Android is nothing more than a sham.
(Important clarification: For the purposes of this article, Android development will refer to actual development of the Android codebase--not developing apps for the Android platform, which is a whole different kettle of penguins.)
Constantinou actually laid out several reasons for knocking down Google's open source claim, including a hard-to-find roadmap, a "gated developer community," and--the one that made me go "huh?"--such hyper-rapid Android development, "OEMs wanting to build on Android have no choice but to stay close to Google so as not to lose on new features/bug fixes released."
Yes, because writing software slowly is a brilliant plan in this day and age.
You can pick apart the other arguments Constantinou made on his blog yourself. Based on the backpedaling he has already done on the original entry, it looks as if Constantinou may be realizing that his arguments are not as strong as he thought. Which is not to say that he is completely wrong; Constantinou senses something is off-kilter about the Google-Android relationship, and is sounding an alarm based on what he understands about open source.
Unfortunately, Constantinou doesn't understand something very basic about any open source project: someone is always going to be in control. Recall that I wrote a while back that open source is not a democracy? Well, open source isn't anarchy, either.
Here's where Constantinou, I think, seriously jumped the tracks:
"Closed review process. All code reviewers work for Google, meaning that Google is the only authority that can accept or reject a code submission from the community. There is also a rampant NIH (not invented here) culture inside Google that assumes code written by Googlers is second to none. Ask anyone who’s tried to contribute a patch to Android and you hear the same story: very few contributions get in and often no reason is offered on rejection."
There's actually two points here that need to be examined. First, that only one authority seems to be in charge of allowing code into the main Android codebase. Well, based on every open source project I have every seen, that's exactly the way it's supposed to be. Whether run by a single person, a group of developers, or an employee inside a corporate entity, at the end of the day someone has to have the final say on what goes into an open source project. Otherwise, you get code created by committee or--worse--a mob.
While it is true that an infinite number of monkeys will eventually come up with Shakespeare, in reality companies can't afford to wait that long for good code. Someone has to take the contributions and figure out a plan to put them altogether in the most efficient way.
To see this in action, you only have to look at the Linux kernel itself. There are, I'm sure, thousands of examples of great code that have been submitted to the kernel over the years, only to be rejected out of hand. Is it because Linus Torvalds and his band of lieutenants are just a bunch of selfish meanies who only want their code in Linux and no one else's?
Not at all. There are scads of legitimate reasons why code might be turned away: maybe there's a license issue, perhaps the code conflicted with other parts of the kernel. Or maybe the kernel developers don't think the kernel needs a device controller for an electric Snuggie. Take your pick.
Now, for every rejection of Linux kernel code, I would be willing to bet that for the most part, reasons for rejection are given to the contributor. If not, it's likely out of oversight rather than a conscious decision to block code for no apparent reason. Is the Linux kernel rejection reporting at 100 percent levels? No offense to the developers, but I'm sure it's not. People get busy, other priorities come up, and things get lost in the shuffle. Unfortunate but true.
This brings up Constantinou's other point buried in the "closed review process" argument: he accuses Google of rejecting code out-of-hand, with "no reason... offered on rejection."
It should be noted that I don't know if Constantinou claim that this is a widespread problem is true. I don't know if Google is blowing off contributions for no good reason. But let's assume Constantinou has done his homework here and there is indeed anecdotal evidence that Google is being very stingy on allowing contributions to Android. If this is true, does that mean that Android fails the open source test?
Nope. It means that Google may be jerks, but not that Android is in any way closed.
Remember, the basic definition of open source is that code is accessible and can be modified under the specific terms of whatever open source license is applied to the code. It doesn't mean that whoever's running the project has to let everyone play in the sandbox. Mind you, they should, because open collaboration and contributions are what make open source projects healthy and project members happy. But if the project owners want to be a--holes about it, they can be.
Why? Because when all is said and done, if developers truly want to develop code for a project and keep finding themselves getting the brush off, they will grab the code, strip out the trademarks, and boom! a fork is born.
Such an approach is entirely stupid on the part of any open source project's owners, because obviously it's going to bite them on the butt, fast. Developers will either fork the code away (and deplete the main project of valuable developer resources) or go code for another project entirely (and deplete the main project of valuable developer resources). Either way means loss of talent and the risk that another project might eclipse yours in terms of features and innovation.
This is why I'm not sure how accurate Constantinou's claim of Google indifference is. He may have managed to just talk to the ticked-off developers who have had their code rejected (grumpy people tend to be louder), and the submission/acceptance rate for Android might be better than what Constantinou suggests. I honestly do not know, but my gut says the latter may be more likely, because if Android was really that hard of a club to join, it seems like there'd be a lot less developers working on it.
Still, there are problems that are easier to note: Constantinou is correct in noting that the Android roadmap is over a year out of date. Given Google's corporate climate of hyper-fast development, that doesn't surprise me, though it lends more evidence that Google isn't treating its community right. Perhaps they should get a community manager in place to smooth out the Google/community interface, or take other steps to make sure the relationship they have with Android developers remains healthy.
Being open in the literal sense is all about the license. But being open in the truest sense means collaboration and participation by more players.