I’ve been following an interesting discussion on TidBITS Talk about the imminent demise of music-composition software Finale. It seems as though, more and more often, I’m reading about people who feel that they have a big investment in or dependence on a software platform and find that the publisher of that software pulls the rug out from under them. That can take several forms.
Often, the publisher will just stop development because it’s no longer practical or financially viable. I don’t think anyone should be forced to continue producing a product if they’re going to lose money doing so (unless they committed to future support). Still, it leaves the people using the software in the lurch. Often individuals and corporations have invested time, energy, personnel, and expertise in software, often to a degree that far exceeds what they’ve paid in licensing fees. Often, they’re just stuck. Finale’s publisher has offered their customers a discount if they buy a specific competitive product. Still, a Finale user would have to convert their entire library of compositions to the new format and manually review each converted file and fix the inevitable errors that crop up — and they’d better do this before Finale stops working! They’ll also have to invest time learning the new platform, training others with whom they work, and working around any Finale features they’ve depended on that aren’t available in the new platform. All while hoping that the new platform doesn’t subsequently engage in a similar rug pull.
Publishers don’t even have to stop publishing a product. They can simply require their customers to migrate to more-and-more costly subscription licenses (Adobe) or make them purchase expensive feature upgrades just to get a version that fixes a bug in some critical function of the program (Microsoft). Or your software might have fatal, deliberately-installed buggy code that causes the program to become unusable if “activation servers” or other license-enforcement resources aren’t available. Such products are destined to fail if a company goes out of business or simply loses interest in their customers, or is sometimes used for deliberate retaliation if a customer publicly criticises the publisher.
I noticed the Finale discussion because, last spring, I took a music course at a local community college and felt compelled to do some composition. I hadn’t set a score since I was in high school and using a 3-point pen and an ink pot. I decided to try a free and open-source (FOSS) music notation application. I was amazed at what MuseScore could do, but then I was comparing it with a pen and ink. When I asked why there wasn’t much discussion about it, the responses were few and mostly “it doesn’t have all the features I need.” But the entire thread was about how the other commercial products were all lacking features that somebody needed. While I’m not qualified to say if MuseScore is a viable replacement for Finale (I suspect it is for some users, but not for others), I do know this:
-
If you have invested your time and effort into learning to use a FOSS product, and the original developer decides to stop supporting it, you’re not out of luck. The program will continue to work as it always has.
-
If changes in the operating system environment break your FOSS product and the original developer is no longer supporting it, there is a high likelihood that somebody will fork the source code and make a new version that supports the new environment. Often the changes needed are minor, but with a proprietary product there’s no access to the source code. That makes it difficult or impossible for third-parties to create a fix. Further, intellectual property law can make it a felony to do the reverse engineering required to fix the problem.
-
Say the developer bails on a product, and nobody steps up to maintain the platform. If your investment is big enough, and you’re using FOSS, you (or a consortium of users in the same situation) can hire your own engineer to keep the product functioning.
-
If there’s a feature you really, really need, but the developer doesn’t feel it’s worth their effort to implement it or continue supporting it after it breaks, you can organize with other users to create a fork and implement/maintain the feature on your own.
-
Say you’re responsible for the art department of a big marketing firm. One day, without warning, everybody finds they’re locked out of using their image editing and production suite until they agree to terms that allow the software vendor to access and use their work. That wouldn’t happen with FOSS, and if it did you could simply switch to using a fork of the software.
-
You may have seen reports of companies who offered FOSS products who have subsequently changed their licensing terms. Guess what? Under almost all FOSS licensing, such changes cannot be retroactive. You, and other users of the software, are free to fork the old FOSS-licensed version and keep using and improving it.
A half-year or so ago, I switched from using macOS as my daily driver to a FOSS equivalent (Fedora Linux, in my case). I kept my old MacBook Pro around in case I found proprietary files that I couldn’t open under Linux. Surprisingly, not only were there FOSS tools that opened my Mac files going all the was back to 1984, some of those files cannot be opened under current versions of macOS with any legal software. I found one tool, for example, that hadn’t been updated since 2002, but it still worked just fine. Had it been an Apple tool, or a tool from a now-defunct proprietary vendor, chances are I wouldn’t have been able to find a legal copy. (The reasons are complex, with a heavy dose of intellectual property idiocy coming into play.) But the FOSS tools’ creators were free to just leave the software on public repositories and say “I don’t know if this will still work, but you are welcome to try it.”
So before you invest hours of your creative time, or commit your company to a product that might suddenly quit working, or skyrocket in price, or present licensing conditions that simply aren’t acceptable, or lose essential functionality, consider if there are FOSS alternatives. You might save a lot more than just licensing costs.
—2p