sorted by: recent | see :
popular
Content Tagged with matt + Development
How To Build A Web App in Four Days For $10,000 (Say Hello To Matt)
Development
Rails
matt
twitter
codebase
webfaction
ryancarson
The vocabulary of open source development models
James Dixon has given the thumbs-up to my stretching his Bee Keeper analogy to explain open source development models (which is nice) and in doing so has suggested a new term to help quickly explain the difference between vendor- and community- dominated development projects.
The debate about the difference between the two approaches, and the language used to describe them, has been simmering for some time. For some background on it, and an explanation about why it matters, see Ted Ts’o’s post from April.
While the debate may seem like a matter of semantics I agree with Ted that it is important in terms of framing a user’s expectation and understanding of an open source project/product and its potential relationship with the vendor.
This is not to say that one approach is better than the other, but that for some adopters (both corporates and individuals) it is important to know that MySQL is the majority contributer to the development of its database and has the rights that go along with that, while other adopters may be more comforted in knowing that PostgreSQL has a broad and vibrant community.
My perspective is that it is important for (some) customers to be able to understand the distinction, and for that an agreed vocabulary is essential. For an example of why vocabulary is important, consider the role of Cathedral and the Bazaar in providing the industry a vocabulary with which to explain open versus closed development models.
It has occurred to me recently that open source is missing an agreed vocabulary for discussing both development and business models (I’ll leave the business models for another time). The problem, of course, is coming to an agreement.
In his initial post on the subject Ted used the terminology “organic” and “non-organic”, which does work, although as he discovered, some found the term non-organic a little pejorative.
An alternative, suggested by Alex Leverington and originally used in a Harvard business school paper (PDF) is “organic” versus “synthetic”.
While that terminology is probably more accurate it too has some potentially negative connotations. I personally have used the phrases “captive” and “community”, of which the former has obvious negative connotations as far as vendor-led projects are concerned.
In his post referenced above based on my stretching of the Bee Keeper analogy, James Dixon suggests “wild” versus “domestic” could potentially be considered derogatory as far as the community-led approach is concerned. Meanwhile, Ted’s request for suggestions generated a number of possibilities.
Here’s a list of the potential candidates I’ve identified. Take your pick, or feel free to suggest any others:
MySQL licensing redux
After all the fuss it appears that MySQL will be remaining open source after all. As Kaj Arno and Monty Widenius report, Marten Mickos announced at CommunityOne that the MySQL Server will stay open source, as well as the forthcoming encryption and compression backup features, which MySQL had considered making available only to paying customers.
“The change comes from MySQL now being part of Sun Microsystems. Our initial plans were made for a company considering an IPO, but made less sense in the context of Sun, a large company with a whole family of complementary open source software and hardware products,” writes Kaj.
“My hope is that the experiment when it comes to closed source extensions developed by Sun is now ended. As far as I know, there is no existing plans for any closed source extensions to the MySQL server,” adds Monty.
While that seems pretty clear cut, there is still room for a little confusion. Kaj writes: “To financially support MySQL?s free and open source platform, we have a business model which allows both community and commercial add-ons, and we remain committed to it.”
Monty clarifies: “I interpret this, in the context of Mårten’s and Jonathan’s announcements, that we will continue to support and make available commercial addons to the MySQL server from third party, like the Infobright storage engine. Things that we develop ourselves at Sun, at least on the server, will continue to be open source.”
UPDATE - The phrase “at least on the server” is revealing, however. Matt Asay points out that MySQL will continue to develop commercial add-ons above the server, which is the direction as I understand it, and - as I noted two weeks ago - has been the direction for some time. - UPDATE
While we’re on the subject of MySQL (again) it’s also worth taking a look at the slides (PDF) from Monty Widenius’s “Future Design Hurdles to Tackle in the MySQL Server” presentation at the recent MySQL Conference and Expo.
The slides provide a fascinating insight into the technical challenges Sun and MySQL face in positioning MySQL for wider adoption, as well as evidence of the intention to be more open, both about the nature of the challenges and in accepting more contributions from outside the company.
As slide 18 states, the fact that the MySQL community is not currently contributing to development means that the project is not benefiting from the experience of real-world users and that the user base is growing slowly.
The suggested solution is to open up the development process to give outside developers commit and decision rights and to learn from how PostgreSQL is developed. I previously wrote that “if MySQL does choose to develop closed source extensions to the GPL code it will probably have to find some way of balancing that with providing more value to the community.”
It would appear that the development of close source extensions is no longer an issue, but that providing more value to the user community remains a priority. Sun has gained a lot in acquiring MySQL, but one thing it hasn’t gained is an understanding of building a wider developer community. In fact, MySQL has a lot to learn from Sun in that regard - both its successes and its failures.