The Coccinella IM project published an interesting entry on potential marketing impact of synchronized software releases:
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.
Synchronized, or timed and regular software releases are already being utilized for example by the Ubuntu distribution. This helps companies and individual end users to carefully plan their upgrade strategy. But in addition, it makes it easy for technology writers to write about the new releases. When plans and schedules are clear, articles will more likely appear.
With Midgard, the project is riddled with very varying release cycles. At the moment we're simultaneously working on major releases in two different generations of the platform, and on top of that actively maintaining and developing the stable 1.8/2.8 branch.
This has led to the situation where testing cycles can be excessively long. For example, MidCOM 2.8 was in beta for ten months, and has seen 13 minor updates since the stable release. Similarly, Midgard 1.8 is in its eight update. And documentation has a hard time staying up-to-date with all this.
This would already make keeping up with Midgard difficult, but the situation is exacerbated by the fact that Midgard can be so many different things:
For some developers Midgard means the libmidgard object persistence and replication library, and its various language bindings. For some it is MidCOM, an MVC framework for PHP that can be used to build any kind of web services. For some it is a component specific for a task like event registrations management or direct marketing. And finally, for some it is a full end-user application suite like Midgard CMS or OpenPsa.
Midgard is a good tool. We have lots of great code and functionality, and a nice community to top that off. But for a regular end user of free software it is very difficult to understand the whole Midgard ecosystem, and where is sits with competition on the various layers. On CMS (or applications) layer we're competing with the likes of Drupal and Plone, on MVC framework layer with Ruby on Rails and Django, and so on.
So, how to move forward? Here are some ideas:
Differentiate the various layers, and their individual components more clearly marketing-wise. Instead of calling all of this Midgard we should introduce names for different collections. This is what we used to do with Aegir CMS in early 2000s with great results, and what has worked very well for the Mozilla project.
In this scenario Midgard would be the central community name, and probably the name of the persistence layer. The other tools would use their own marketing names. Also components would get rid of their too techy namespace-based names and use something more human readable in their marketing.
This also means redesigning the Midgard site to provide more visibility to the different parts. Something closer to the maemo application catalogue would be far better than our current component list.
Synchronize releases. This could mean digging up the time-based Midgard release process proposal from mothballs, or just ensuring that libmidgard, MidCOM, documentation and the important components all are developed in sync with each other. On wider scale this could also mean trying to keep the pace with releases of dependencies like PHP and libgda, or with important platforms like debian and RHEL.
This probably requires finding new resources and tools for testing and documentation. For example the unofficial Midgard wiki is often in better state than the official one, so why not merge them? Similarly, keeping downloadable virtual machine images available should make testing new Midgard releases a lot easier.
These of course are just ideas. In any case the transition to Midgard2 makes it possible for us to rethink a lot of these things.
