Going open source...
This presentation was based on Lars Thalmann's (http://larsthalmann.com/) experience with MySQL cluster that was developed at Ericsson R&D and was later purchased by MySQL.
Ericsson Business Relations (a unit within Ericsson) managed this project in its early days. Focus was on availability (5 nines) and long sales/deployment cycles. The development model was traditional and closed source. Only customers saw the software - no free downloads. Ericsson had its own internal API and a SQL layer and ODBC layer to be accessible to the outside. Then things changed. Ericsson started to cut down on its assets. Ericsson lost interest in this clustering technology as it wasn't really Ericsson's core competency. On the other hand, MySQL needed a solution in the cluster database space, so the sale came about.
After its sale to MySQL, the cluster layers were eventually integrated into MySQL's server, which has a better SQL layer. One huge challenge was to reduce installation time from 1-2 days to about 15 minutes. The software needed to be easy to install and use because open source developers typically have low attention span and little patience when looking for solutions. Documentation, which existed internally was about 15 pages long with a large share of the knowledgebase was tacit, but had to be expanded to spell out everything. The manual grew to 115 pages!
Making source code available to the world gets complicated. The steps taken with MySQL cluster in brief:
- Add plenty of comments.
- Be comprehensible.
- Sloppiness gets discovered quickly. Feedback cycles improve, however.
- Be open to criticism.
- Use dual-license model to keep the revenue stream going.
- All bug reports had to be published on the web. Deal with it!
- Distributed team: Knowledge goes from tacit to explcit.
- One example is sending plain text e-mails - no word documents. About 250 e-mails a day (grown tenfold).
- Interestingly, messaging system of choice is IRC. Netiquette is that you ping via IRC before calling on the phone.
- Every developer suggests their own roadmap. Closely mimics Agile methodology.
- Initially difficult to adapt to constant feedback on several releases.
In brief, according to Lars, his team moved from (availability, performance, scalability) to (reliability, performance, ease-of-use).