Sebastian, thanks for providing your perspective. On Tuesday, November 12, 2013 07:18:43 PM Sebastian Schelter wrote: > The lead developer of Impala answered the question whether Impala accepts > patches with the statement that Impala is developed by Cloudera engineers > and others can only look at the source code on github...
I'm intentionally taking out only this comment and putting my ASF member hat on for a second: There's a couple of ways for running open source projects. Compared to how in the past large corporations abused the term open source* to turn it into "shared source" - what you describe above actually isn't so bad at all: The license is a valid (as in OSI approved) open source license that gives users of the project all four freedoms**. So if someone wants to change the project in a way that is not compatible with the way Cloudera wants to drive the project, they can simply clone the project, make modifications and pull changes from upstream in a timely manner. If there's more than one such person it's easy enough to establish a new community leader who clones the project, fetches and merges from upstream in a timely manner and manages patches from downstream contributors. In order to make this fly it needs a bit of experience, a whole lot of dedication, quite some time and some knowledge in herding cats^W^W^W with managing a community of developers. Essentially it's not unlike other open source projects controlled by a single entity only: You end up with a benevolent dictatorship where the dictators power is limited by the forkability of his project. The way Mahout works is fundamentally different: Instead of having one entity with full control over development direction those actively contributing to the project earn merit over time - with merit comes more influence on the code base (and, granted, more responsibility). This particular aspect may seem incredibly unimportant when you are starting a new project at your employer. However software projects tend to live much longer than originally anticipated. So if you bet part of your business on an open source project, it seems worthwhile to put some thought into how you can assure that the project isn't going into a direction that is completely at odds with what you want to do. Of course with this freedom comes responsibility: Giving a say in the project to multiple entities means that there is more need for communication before reaching consensus and going with that decision. On the other hand getting to the point where one can influence the project needs active participation - much like Mahout itself depends crucially on it's users contributing code, documentation and help on mailing lists. See also the following two texts on how open source works - though the umbrella project that published them is no longer active the content is still relevant today: http://jakarta.apache.org/site/contributing.html http://jakarta.apache.org/site/understandingopensource.html For founders openess comes with giving up direct control over what that person may consider their personal baby. However it also comes with the virtue of knowing that the project has a chance to survive the founder's interest in and time for it - essentially giving it a chance to stand and live on it's own. It may be my personal bias however I have met many people (not counting Apache Software Foundation people obviously) who value having the freedom to participate, to drive the project further and to be able to influence the project themselves in particular when betting parts of their business on that project. For interested in a bit more background information on what the typical options for open source governance are it might be valuable to take a look at the following text: http://producingoss.com/en/producingoss.html#social-infrastructure Sure it's sad for Mahout to see someone very capable leaving. It's also sad to see a project being founded with a proposal that for the uniniated is hard to distinguish from Mahout's offering. However sometimes it's better to try out new ideas in a space independent of the original project as opposed to becoming ever more grumpy with not being able to persue one's own ideas of how things should be. Who knows, given how different the two projects are according to Sean - maybe there's room for mutual benefit after all. I certainly welcome contributions in that direction. Isabel * http://en.wikipedia.org/wiki/Shared_source ** http://fsfe.org/freesoftware/basics/4freedoms.en.html
