The Blessings of Synchronized Releases

People believe the idea of synchronized jumping to releases originates from Mark Shuttleworth.
People are wrong!

Back in 2006, the Eclipse Foundation pioneered synchronized releases with Callisto:

The Eclipse Foundation is making history this week with what looks to be the largest ever synchronized open-source project release. The Callisto Simultaneous Release initiative coordinates 10 Eclipse project upgrades [..]

Only since 2007, about a year after Callisto, Shuttleworth started singing in tune. Nonetheless, the impact was greater as he continued practicing the art of synchronicity with much enthusiasm. Later, the choir grew when others started singing about the benefits of a regular release schedule, about cross project synchronisity, about release dates for Debian, about free software syncronicity, and about synching the open source release schedule.

Instead of repeating what has already been said in the above writings, I will focus on explaining the key blessings of synchronized releases. What are the huge potentials of synchronization for the broader open-source community? Why did we adopted the synchronization strategy? And why should your project consider adopting it as well?

Stevenotes and Windows Launch Events

What do Stevenotes and Windows launch events have in common? Yes, they both result into a flood of publicity. When Steve Jobs speaks, pregnant women's magazines write about it. When Microsoft spends a little money, the television journal will show us impressive fireworks that make New Year's Eve look like a non-event. All media eagerly report about these happenings!

The picture is very different for the open-source world. When a small open-source projects such as Coccinella issues a new release, you may at best see a review by a blogger or by some obscure local computer magazine. It gets slightly better with bigger projects which may attract the attention of several bloggers and a dozen computer related news sites. Even more, the real big projects may sometimes even go a bit further. However, no open-source project approximates what Apple and Microsoft do. No pregnant women's magazine writes about Firefox 3 and the television journal will not be interrupted for a boring interview with some geeks about Ubuntu's Intrepid Ibex.

How can we copy the marketing successes of Apple and Microsoft to open-source? Some may suggest we need someone like Steve Jobs, whilst others would like to spend more money on launch events. They are both wrong! Trying to copy Steve Jobs or Microsoft's deep pockets is mission impossible. If Apple or Microsoft notices we are trying to catch up, they will simply improve their key strategic advantages and catching up will become even more challenging for us. What do we have to do then?

Community is in what we excel; our key strategic advantage. To repeat the marketing success of Apple and Microsoft we need to leverage the community. Massive synchronized releasing is the perfect tool to achieve this leverage. By synchronizing, release related marketing efforts of multiple communities are focused at the same moment and can leverage each other. The rhythm of so much projects doing their marketing efforts at the same moment will shake the Internet. I'm sure the pregnant women's magazine and the television journal will feel these shakes...

Yes, massive synchronized release cycles have the potential to create a bigger impact than Stevenotes and Windows launch events.

Planning Drupal Upgrade

This website is still powered by the old Drupal 5. Even though its successor has already been released months ago, we cannot tell you when exactly the Coccinella website will be upgraded to version 6. If you are also running a Drupal based website you should have correctly guessed that our website depends on third-party modules. Most of these modules did not had an updated version available at the time of the 6.0 release. Even today there are still plenty of them that have no stable 6.x version or that have no version at all for 6.x! Of course we can look around for alternative modules or we can just drop website functionality, but obviously, both will not contribute to a painless upgrade experience.

I chose the above example because it clearly shows you that synchronized releases also benefit non-business users and not only business users. If Drupal and its third-party modules had adopted a synchronized release scheme, we could have switched shortly after the 6.0 release, without the need to lose time on looking for alternative modules, and with lower upgrade risks. It would also have been possible for us to plan the website upgrade months before the actual release of Drupal 6. For businesses this translates into 3 cost savings: labor cost savings, risk protection savings, and savings thanks to the possibility to plan the upgrade a long time in advance (e.g. hiring additional employees to assist with the deployment is cheaper when it is done a long time in advance than when it is done only a few days before the deployment). Hence, synchronized releasing adds value for both business and non-business users, upgrading open-source software will be easier and cheaper.

In the long run, we may see an additional blessing of massive synchronized releases in the planning area. When choosing a release strategy for their software, companies who provide cross-platform software may decide to align their release processes to the platform with the best predictable release dates. Accordingly, commercial applications, games, and hardware drivers may closely follow the synchronized release cycle of the open-source world. Compatibility between commercial software and new versions of open-source software thus could be greater than compatibility between commercial software and new versions of proprietary software.

Release-Time Collaboration

When open-source projects synchronize their releases, they all will at any time be in a similar development stage and thus their priorities will better match. It should be clear that collaboration among projects is easier when all noses are pointed in the same direction. Projects will face the same problems and can better understand the needs of other projects. Hence, discussions can be shorter and projects can move forward sooner. More time can be used for coding and thus productivity will increase. Open-source projects will be able to provide their users with more new features, they will be able to fix more bugs, and code freezes can be shorter without losing software quality.

What's Next?

Next week I will write about how we practically implemented synchronized releases at Coccinella. As our experience will show you, adopting synchronized releases does not mean your project loses its freedom. There are multiple ways to implement the synchronization strategy.