Support a Market Leader Early
When Recordare started the MusicXML project, a key milestone was that we be able to read and write MusicXML files from either Finale or Sibelius within a set period of time. If we did not accomplish that goal, we would give up and I would move on to other things. Both in 2000 and today, Finale and Sibelius are the two dominant players in the music notation marketplace. An interchange format that could not support one of these two applications would be of commercial interest to nobody.
On the other hand, once we could do two-way interchange to one of these applications, this opened up a wealth of possibilities to attract other software developers. Developing high-quality music notation display and editing is a very complicated task. By removing the need to duplicate what Finale and Sibelius provided, we would lower the barrier to entry for innovative new music applications. Of course, we would also be lowering the barrier to entry for competitive applications, so neither Finale nor Sibelius had much incentive to help us with this project. We hoped that they would see the benefit to them once we had working software, but we never expected these entrenched market leaders to give us help in our initial development work.
Both Finale and Sibelius provide plug-in development kits so that third-party developers can write add-on software to their applications. It quickly became apparent that only Finale’s was capable of two-way interchange, so that is where we focused our efforts. Building a translator that supports major, feature-rich commercial applications at a reasonable level tends to be a substantial undertaking. We therefore held off on doing this until our experience with the initial prototypes satisfied us that our basic MusicXML design was on the right track.
Once we had a working plug-in for Finale that we were willing to alpha test outside Recordare, we started approaching third-party developers. Our first obvious target was Graham Jones, developer of the SharpEye Music Reader software. At that time, each notation editor had its own captive scanning program. Finale worked with the SmartScore family of products provided by Musitek, while Sibelius worked with the PhotoScore family of products provided by Neuratron. SharpEye Music Reader had developed a reputation for scanning accuracy equal or better than these programs. But it could only use MIDI to transfer music into the notation editors, negating the advantages of the program’s internal scanning accuracy.
Graham Jones saw the opportunity, even though he was not happy about having to duplicate work that he had already done to export NIFF files. Since MusicXML is farther from the internal structure of scanning applications than NIFF is, it would be even more work to support MusicXML. But the benefits from being able to better sell to Finale users was worth the cost, and in September 2001 SharpEye became the first commercial product to support the MusicXML format. The makers of Finale then saw the advantage of having a scanner like SharpEye work better with their program. They started including MusicXML support based on Recordare’s Dolet® software technology with the Windows release of Finale 2003. SharpEye was Windows only, as was the original version of our Dolet plug-in software, so built-in Macintosh support did not get added until Finale 2006. Universal binary support for Macintosh was added in Finale 2007.
Figure 1 reflects MusicXML’s implementation status after SharpEye had shipped, but while our Dolet for Finale plug-in was still in beta test. The change from Figure 1 to Figure 2 shows the order of magnitude increase in MusicXML support over the past 5 years. As we had thought, having MusicXML support for Finale was a key element in attracting other software developers to the format.
The next major challenge was to add MusicXML support for Sibelius. The original Sibelius plug-in development kit contained no way to interact with the computing world outside of Sibelius, such as through reading or writing a text file. The necessary features for MusicXML export were added in version 2.1, but not documented until version 3.0. We created a plug-in for Sibelius export soon after one of our customers directed our attention to this newly documented feature. The capabilities of the exporter increased as Sibelius increased the power of the plug-in environment to meet their own application needs. Sibelius added built-in MusicXML import support when Sibelius 4 was released in 2005. This was done primarily to import Finale files more accurately than had been possible with their own special-purpose Finale translator. This became feasible once Finale provided built-in MusicXML support on both Macintosh and Windows. MusicXML export in Sibelius 4 still requires our separate Dolet translation plug-in.
The music scanning world also adopted MusicXML more widely once SharpEye and Finale supported it. PhotoScore Professional added support for version 3 in 2003; Kawai SCOREMAKER for version 4 in 2004, and SmartScore for most editions of version 5 in 2006. Music scanning and notation programs can now be freely mixed and matched based on customer needs, rather than being restricted through vendor tie-ins.
It is difficult to underestimate the importance of having an XML interchange format support a market leader early in the process. If your so-called standard format does not support at least one of the most popular programs in the market, why should you expect anyone to adopt it? This support is the responsibility of those who want the XML interchange format to succeed. It seems naive or cynical to expect the market leader to do this for you. It is rarely in their business interest to invest time and money in doing so. However, once support is available independently, market leaders may find a way to turn it to their advantage, as happened with MusicXML. This dynamic is becoming more important today, as more and more people realize the importance of open file formats for long-term use and preservation of computer application data.
Fortunately, in many application areas the market leaders have a plug-in development environment at least as good as what was available to us in Finale 2000. This is exactly what is needed for format proponents to build their own support for the market leader. Proprietary file formats are rarely documented, but documented plug-in environments that can access the file format are much more common. Many of these plug-in environments are much more mature than what we had to work with to build our initial MusicXML plug-in for Finale. Our progress would have been far more rapid if we had access to a plug-in development environment as mature as the one that Microsoft provided as far back as Office 97.
