Sparse notes from the talk, I noticed Sheeri recording some video, so sitting through that at some stage might make sense. There were no slides, this was a panel discussion. Suggested reading: Organic vs. Non-organic Open Source.
Does Open Source need to be “Organic”?
Brian Aker, Rob Lanphier, Stephen O’Grady, Theodore Ts’o
Taking code, and slapping a certain license on it, doesn’t a successful software project make.
Blurring the distinction, by marketing. Not doing any work to get external contributions.
Open sourcing a product one plans on “genociding”, its really bad.
“Corporate sociopathic Druckerism” — Brian Aker
“As long as the source code is open, let the market decide. MySQL is largely inorganic, and its a success. Much of it comes down to choice.” — Stephen O’Grady
Mark Shuttleworth has pushed the idea that forking is OK. Look at Launchpad: take a project, fork the project, make your change, and you can publish your tree that people can use. The wonders of distributed version control.
Its up to a company to decide if they want an organic or an inorganic project. Its your code, do what you want with it. In the future, an organic project may outstrip your inorganic project.
Netscape: inorganic piece of open source (with Mozilla). Firefox: forked the code, turned it into an organic model, then there was success.
Is Firefox really the best example? Look at what it did for Netscape Corporation or AOL? This won’t work well with the Pointy Haired Boss.
What was your goal of releasing the product under an open source license? If marketing buzz, then you make lots of PR, etc… then go home. If your goal is wanting to cut your development cost, you’re going to be disappointed with an organic model. If your goal is ubiquity, you aim for an organic model.
Commit access actually means you’re a worker bee. It doesn’t mean a free wheel to push features, it means you’re the garbage man - you collect everything, you sort everything, and so on. Let’s rethink what it means to have commit access.

Since I didn’t have any MySQL public courses planned this summer, I’ve been using my work time from the last week in the new eBox website.
I’m still far away from what I’d like, but I’m proud my design skills have improved considerably.
For those of you who still don’t know what it is, eBox is a server for the easy administration of corporate networks. eBox was included with the last release of Ubuntu. See eBox in Ubuntu
I was sitting in a train in the middle of rainy Ireland when I received a mail that Nokia has bought Symbian and is releasing it as Open Source. I didn't believe a word of it. But the web was full of news about it, so it was true. This is an amazing turn of events that I didn't anticipate at all. (You may or may not know that in my previous job I was heavily involved with Symbian programming. Ironically, one reason I left just 6 months ago is that I wanted to work in an Open Source environment :-)
I've been at MySQL for two and a half years now as a community manager. Through this time, I've learned a number of valuable lessons about what it means to be a community manager, what it means to belong to a community of technologists, and what it means to be an open source advocate. I think back now on the attitude and preconceptions I brought with me when I joined MySQL, and reflect about the changes in my own attitude that have happened.
One of the biggest "aha" moments I have had in the past three years is the following:
It is the role of a community manager to remove the barriers — both technical and ideological — between the user/developer community and the company or group of individuals which produces the open source software
Some barriers are small. Sometimes these barriers can be overcome by a simple email to an annoyed community member who has misunderstood a poorly communicated company objective.
And, sometimes barriers are large, and require a concerted effort of many people to overcome. One of these large barriers — the usage of the closed-source BitKeeper source control system — was recently removed and is a shining example of what can happen when many advocates within a company come together for the benefit of the community as a whole.
Yesterday, Kaj Arnö announced that MySQL has officially moved away from BitKeeper and has shifted development to use the free and open source Bazaar revision control system. This is an immensely important move for the MySQL community and the MySQL engineering team and its importance cannot be understated. While BitKeeper is technically a fast and feature-full revision control system, there was a significant barrier to the community that it enforced: the free BK client was essentially a read-only client, without even basic abilities to do diffs on a source code branch. This inhibited contributions from the external community by pipelining contributions into closed BK branches with no commit access for external contributors.
With the move to MySQL hosting its source code on the Launchpad.net service in Bazaar trees, we have removed this barrier to open source development. On Launchpad, there is now an overarching mysql super-project which contains all MySQL-related projects. Under this super-project, there are two projects which contain branches of the MySQL Server. One project, "mysql-server" contains the official MySQL server code branches. The other, "sakila-server", contains branches of the server codebase that are being worked on by external community members.
Why did we set up two separate projects, one called "mysql-server" and one called "sakila-server"? There are a number of reasons.
First, and perhaps most importantly, the "mysql-server" project contains all official branches and MySQL engineering team trees. Consequently, the code area of Launchpad for this project, is beginning to fill up with lots of different branches, and it is a little difficult to differentiate which branches are written by community members. We wanted a separate area that community members could showcase their work, and not have their work "swamped" by all the different team trees.
Secondly, one of the issues we ran into was how do community-written projects track roadmap tasks or bugs in their distribution? MySQL has its own Bug Tracking system and its own Worklog system which it uses to track "roadmap" type tasks. Unfortunately, there is no way for community-developed projects to use these systems, as they are heavily customized for MySQL's internal procedures. Furthermore, Launchpad.net already offers services for tracking bugs and assigning roadmap tasks to projects. So, with a separate sub-project (sakila-server), community developers now have a built-in bug and blueprint (roadmap) services ready to use for their code branches.
Finally, within the "mysql-server" sub-project, community members wouldn't have the rights to "brand" their projects the way they wanted to. As MySQL is a trademarked and copyrighted product, community members would be restricted to how they could administer and brand their own branches. Having their branches under a separate sakila-server sub-project, those restrictions go away and they have full administrator rights over everything, including branding...
I think this move is fantastic, and we welcome your input and feedback about ways we can continue to open up, be transparent, and work better with our community. We're all ears. Let a hundred dolphins swim.
Please be sure to check out both server code project areas and investigate the various branches that community members are working on!

The Red Hat Summit started today here in Boston. Based on the evening reception today, it is shaping up to be a pretty good show. I will be speaking at the show on Thursday, June 19, 2008 at 11:30 AM eastern time. I will discuss current state of open source backup as well as where things are headed. We also have a booth located towards the right side of the exhibit floor (by small meeting rooms). We are demonstrating Amanda as well as ZRM for MySQL.
Do stop by if you are coming to the show!