Alex Stetsenko

P.S.: hundredth post!

Dries Buytaert did some research and compiled a timeline of MySQL AB’s history.

1995

• MySQL AB founded by Michael Widenius (Monty), David Axmark and Allan Larsson in Sweden.

2000

• MySQL goes Open Source and releases software under the terms of the GPL. Revenues dropped 80% as a result, and it took a year to make up for it.

2001

• Mårten Mickos elected CEO at age 38. Mårten was the CEO of a number of Nordic companies before joining MySQL, and comes with a sales and marketing background.
• 2 million active installations.
• Raised series A with undisclosed amount from Scandinavian venture capitalists. Estimated to be around $1 to $2 million.

2002

• MySQL launched US headquarters in addition to Swedish headquarters.
• 3 million active users.
• Ended the year with $6.5 million in revenue with 1,000 paying customers.

2003

• Raised a $19.5 million series B from Benchmark Capital and Index Ventures.
• 4 million active installations and over 30,000 downloads per day.
• Ended the year with $12 million in revenue.

2004

• With the main revenue coming from the OEM dual-licensing model, MySQL decides to move more into the enterprise market and to focus more on recurring revenue from end users rather than one-time licensing fees from their OEM partners.
• Ended the year with $20 million in revenue.

2005

• MySQL launched the MySQL Network modeled after the RedHat Network. The MySQL Network is a subscription service targeted at end users that provides updates, alerts, notifications, and product-level support designed to make it easier for companies to manage hundreds of MySQL servers.
• MySQL 5 ships and includes many new features to go after enterprise users (e.g. stored procedures, triggers, views, cursors, distributed transactions, federated storage engines, etc.)
• Oracle buys Innobase, the 4-person Finnish company behind MySQL’s InnoDB storage backend.
• Ended the year with $34 million in revenue based on 3400 customers.

2006

• Mårten Mickos confirms that Oracle tried to buy MySQL. Oracle’ CEO Larry Ellison commented: “We’ve spoken to them, in fact we’ve spoken to almost everyone. Are we interested? It’s a tiny company. I think the revenues from MySQL are between $30 million and $40 million. Oracle’s revenue next year is $15 billion.”
• Oracle buys Sleepycat, the company that provides MySQL with the Berkeley DB transactional storage engine.
• Mårten Mickos announces that they are making MySQL ready for an IPO in 2008 on an projected $100 million in revenues.
• 8 million active installations.
• MySQL has 320 employees in 25 countries, 70 percent of whom work from home.
• Raised a $18 million Series C based on a rumored valuation north of $300 million.
• MySQL is estimated to have a 33% market share measured in install base and 0.2% market share measured in revenue (the database market was a $15 billion market in 2006).
• Ended the year with $50 million in revenue.

2007

• Ended the year with $75 million in revenue.

2008

• Sun Microsystems acquired MySQL AB for approximately $1 billion.
• Michael Widenius (Monty) and David Axmark, two of MySQL AB’s co-founders, begin to criticize Sun publicly and leave Sun shortly after.

2009

• Mårten Mickos leaves Sun and becomes entrepreneur-in-residence at Benchmark Capital. Sun has now lost the business and spiritual leaders that turned MySQL into a success.
• Sun Microsystems and Oracle announced that they have entered into a definitive agreement under which Oracle will acquire Sun common stock for $9.50 per share in cash. The transaction is valued at approximately $7.4 billion.

The fact that Twitter and Digg are replacing MySQL by Cassandra have become very popular.

However for me it was also interesting to find out how Twitter engineers had conducted their research and what other solutions had considered.

For example, there are questions to evaluate potential tool:

• How will we add new machines?
• Are their any single points of failure?
• Do the writes scale as well?
• How much administration will the system require?
• If its open source, is there a healthy community?
• How much time and effort would we have to expend to deploy and integrate it?
• Does it use technology which we know we can work with?… and so on.

And they had to check various databases: HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable.

Another interesting fact is that Twitter guys actually test on production.
For instance, to roll out the new data store they:

1. Write code that can write to Cassandra in parallel to MySQL, but keep it disabled
2. Slowly turn up the writes to Cassandra (it can be done by user groups like “turn this feature on for employees only” or by percentages “turn this feature on for 1.2% of users”)
3. Find a bug 🙂
4. Turn the feature off
5. Fix the bug and deploy
6. GOTO #2

Eventually 100% doubling of writes are being done.

Read more details in the interview where Twitter Storage Team Lead Ryan King talks about the reasons for the switch and how it is planned to migrate tweets from MySQL to Cassandra.

In case you don’t know where to start with Scrum or just need a reference for further research, Geir Berset made a short, stripped down introduction.

1. Create and maintain a product backlog. This is a list of functional and non-functional requirements sorted by importance, and given estimates on a “best guess”-basis. These requirements should be understood by the customer (Product Owner).
2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog. The team break these requirements into actionable items (tasks), and carefully adds their estimates. A goal is constructed for the sprint that the team can commit to. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later.
3. Do the sprint (with daily scrums). The team carries out the sprint during the coming month, and scrum masters (managers) are mere facilitators at this stage. The team self-organizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) of only 5 to 15 minutes duration regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me to do what I plan to do?
4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review.
5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving in the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints.
6. Repeat every 30 days.

Obviously this list of activities is not enough for team and project success. But it is a good start to review each of these topics in more detail and ultimately get benefits from Scrum.

There are many books and articles have been written to answer this question. It is possible to find many interesting ways and techniques like prepare agenda, hand-outs, limit meeting time, meeting leader etc.
However recently I have discovered one more trick to make meetings short and effective. The best part of it is no requirements on either any special knowledge nor expensive equipment.

So the solution is very simple – conduct stand-up meetings! 🙂

Normally standing people want to sit after a short period of time. However it won’t be possible until meeting is done. As result there should not be any talks on unrelated topics because after a few minutes everyone wants to sit.
So attendees will speak on subject strictly as well as make decisions faster. Which means meeting is going to be short (topic related discussions only) and effective (decision is required to stop the meeting).
Additional ‘side effect’ is that teams could have such meetings more often without much loss of productive time.

The only disadvantage is that it might not be easy to make some attendees to stand…