I grew up in Oklahoma. For my international readers (I have quite a few), Oklahoma is in the central US, is quite beautiful, and is often called the “belt buckle” of the “bible belt”. This last characteristic gives way to some quite asinine laws, one of which is that beer sold in Oklahoma grocery stores must no more than 3.2% alcohol. As a kid I remember people ridiculing Oklahoma’s “near beer” to my father who would inevitably retort, “The 3.2 restriction is by weight while liquor stores measure by volume so it’s not a big deal.” I know–it always sounded lame to me too, but he’s a mathematician. (For details on the math, look here).

One of the criticisms of Alfresco by hardcore open source types is that it isn’t really open source. Like my home state’s beer, it’s almost open source. What does this mean? Certainly, the reasons I cited as to why clients choose open source (fit, standards, source code, transparency) hold true for Alfresco (See this post). But there’s a characteristic of “true” open source projects that’s missing for Alfresco that may not be as high on clients’ care-abouts, but is important to those of us in the community and that is this: In the current Alfresco model, none of us can ever be a committer. Yes, you can contribute patches and enhancements by opening a Jira ticket, but you’ve got to be an employee to be able to write to the SVN repository.

In the early days of Alfresco, this was more defensible than it is now–the code lines were the same, the product was still maturing, and, most importantly, Alfresco needed to protect its interests. Alfresco didn’t necessarily have time to let the community take the product wherever it wanted to. Instead, it needed to establish a critical mass, get things pointed in the right direction, and get some maintenance subscriptions flowing. Unlike other open source projects that start altruistically, Alfresco was a commercial enterprise from the start and there’s nothing at all wrong with that.

But now things have changed. There have been over 1 million downloads. There are tens of thousands of registered members of the community. The Community and Enterprise code lines have been separated. Why not give up some of the control of the Community edition to the, uh, community? Alfresco is still a small company with limited resources. Couldn’t a fraction of those thousands of registered developers be enlisted to help?

Alfresco often compares its model to that of Fedora/RHEL and JBoss.org/JBoss.com which is a good way to illustrate the difference between Community and Enterprise from a development build versus enterprise-ready build perspective. But what about the development model? For those not familiar, the JBoss Development Process is roughly that all code starts in JBoss.org where it is available to early adopters. When it starts to look viable, it is pulled into JBoss.com, where it is scrubbed (maybe even recoded), integrated with the rest of the platform, tested, and productized. The key difference is that JBoss.org contributions include not just JBoss employees but others in the community who’ve earned the right to do so. Why can’t Alfresco work this way?

I imagine the answer comes down to resources and control. I concede that having the same engineers contributing to Community that must then pull the features forward into Enterprise is very efficient. Especially In the beginning, I could see how Alfresco engineers might have to spend more time integrating Community code with Enterprise code than they would have under the closed community policy. Surely that would improve over time, though.

Regarding control, I can understand that a commercial software company would feel inclined to tightly control the project’s growth and that an open community would be seen as a threat to that. But if the community takes the product down a substantially different path than the planned roadmap, wouldn’t that tell you something? And this wouldn’t be completely giving up control–Alfresco product management and Marketing would still be responsible for understanding what clients want, setting the road map, and owning the overall vision.

Maybe this is something we can get John and others to talk about next week in San Jose. Over a beer.