also important to note that proprietary vendors often drop support for their products over time; there is no real recourse for proprietary products users, while there are recourses for OSS/FS users. There are many organizations who provide traditional support for OSS/FS for a fee; since these can be competed (an option not available for proprietary software), you can often get an excellent price for support. Again, an anti-trust lawyer would say that OSS/FS support is “contestable.” For example, many GNU/Linux distributions include installation support when you purchase their distribution, and for a fee they’ll provide additional levels of support; examples of such companies include Red Hat, Novell (SuSE), Mandriva (formerly MandrakeSoft), and Canonical Ltd (which supports Ubuntu, a derivative of Debian GNU/Linux). There are many independent organizations that provide traditional support for a fee as well. Some distributions projects are actively supported
by a large set of companies and consultants you can select from; examples include Debian GNU/Linux and OpenBSD. The article ‘Team’work Pays Off for Linux evaluated four different technical support services for GNU/Linux systems, and found that “responsiveness was not a problem with any of the participants” and that “No vendor failed to solve the problems we threw at it.” Many other organizations exist to support very specific products; for example, Mozilla Firebird and Thunderbird support available from decisionOne and MozSource, for many years AdaCore (aka AdaCore Technologies or ACT) has sold commercial support for the OSS/FS Ada compiler GNAT, and MySQL AB sells commercial support for its OSS/FS relational database system. It’s very important to understand that OSS/FS support can be competed separately from the software product; in proprietary products, support is essentially tied to purchase of a usage license.
In the meantime, users can minimize any ‘fitness for purpose’ risks through evaluation and testing, and by only using production releases of well-known, mature products from reputable distributors.” Indeed, this prediction seems nearly certain, since it’s been happening and accelerating for years. As an alternative to paid support, you can also get unpaid support from the general community of users and developers through newsgroups, mailing lists, web sites, and other electronic forums. While this kind of support is non-traditional, many have been very satisfied with it. Indeed, in 1997 InfoWorld awarded the “Best Technical Support” award to the “Linux User Community,” beating all proprietary software vendors’ technical support. Many believe this is a side-effect of the Internet’s pervasiveness - increasingly users and developers are directly communicating with each other and finding such approaches to be more effective than the alternatives (for more on this business philosophy, see The Cluetrain Manifesto). Using this non-traditional approach effectively for support requires following certain rules; for information on these rules, consult “How to ask smart questions” and How to Report Bugs Effectively. But note that there’s a choice; using OSS/FS does not require you to use non-traditional support (and follow its rules), so those who want guaranteed traditional support can pay for it just as they would for proprietary software. Indeed, proprietary software is often informally supported as well. User groups, magazines, and various organizations have been stood up over many years to support proprietary products, even ones that in theory have a formal support channel. This shows that formal support is often not effective, certainly not as effective as the proprietary vendors wish to pretend. But unlike
proprietary software, nontraditional OSS/FS support organizations have direct access to the source code and development information - which means they can be much more effective.
And it’s important to remember that for a proprietary product, the vendor can at any time decide to end support for a product -- while there is always an alternative for OSS/FS users. This is
especially a risk if a company goes out of business, is bought out, changes to a different market, or if the market becomes too small. But this can happen even when the company is profitable, doesn’t change its basic market, the market is large, and there are many established users. After all, the vendor may have priorities not aligned with yours, and the vendor is usually the only organization that may make improvements and sell the product.
An extreme example of how a commercial vendor can abandon its users has been Microsoft’s abandonment of the vast number of companies who use Visual Basic 6. Many large organizations have developed large infrastructures that depend on Visual Basic 6, and one survey reports that 52% of all software developers use Visual Basic (at least occasionally); one developer estimates that this plan abandons about 18 million software developers, of which an estimated 6 million are professionals, who developed tens of millions of Visual Basic applications. When Microsoft developed its “.NET” infrastructure, it also created a new product that it called “Visual Basic for .NET” (VB.NET). Unfortunately, VB.NET is completely incompatible with the Visual Basic 6
language so widely used by industry, so the millions of lines of code written using Visual Basic over many years cannot be used with VB.NET without essentially rewriting the programs from scratch. (the migration wizard is essentially useless because there are just so many
incompatibilities). A former Microsoft VB product manager, Bill Vaughan, coined the name “Visual Fred” for VB.NET to emphasize how different the new product was from the old one, and the term “Visual Fred” for VB.NET rapidly caught on. This is an enormous expense; if it takes on average $4,000 to to rewrite a Visual Basic application, and only 10% of an estimated 30 million applications need to be rewritten, that means customers will end up paying $12 billion dollars just to rewrite their software (without new functionality). Surveys show that Visual Basic 6 is still far more popular than VB.NET; a 2004 survey found that 80% used Visual Basic 5 or 6, while only 19% used VB.NET. A protest petition has been signed by more than 2,000 people (including 222 MVPs), and many companies have complained about the enormous and completely unnecessary expense of rewriting their programs just because Microsoft stopped supporting the original
language. Nevertheless, Microsoft has decided to abandon Visual Basic 6 (mainstream support for VB6 ends on March 31, 2005), in spite of the outcry from most of its users. Since there never was a standard for Visual Basic, and its implementation is proprietary without obvious alternatives, Visual Basic 6 users are stuck; they cannot take over development themselves, as would be
possible for an OSS/FS program. Instead, the majority of Visual Basic developers are switching to other languages, primarily C# and Java. For example, Evans Data found that of those who weren’t staying with Visual Basic 6, only 37% of Visual Basic 6 users planned to switch to VB.NET; 31% said they plan to move to Java and 39% said they will be migrating to C#. You can see
ClassicVB.org for more information. This has the ire of many who normally support Microsoft; Kathleen Dollard said, “It is unconscionable (and should be illegal) for Microsoft to end
mainstream support until everyone who made a good faith effort in light of their business
environment has made the switch” You could say that this extreme unwanted expense was the just punishment for developers who unwisely chose to use a language with no standard, no alternative implementation, and no mechanism to gain support if the vendor decided to stop supporting the original product. But this is little consolation for those many who have programs written in the now-abandoned Visual Basic 6, since they cannot be handled by the new VB.NET.
In contrast, many OSS/FS programs have been “abandoned” or had major changes in strategy contrary to their user’s interests, but support did not end. Apache grew out of the abandonment of the NCSC web server program -- users banded together and restarted work, which quickly became the #1 web server. The GIMP was abandoned by its original developers, before it had even been fully released; again, users banded together and refounded the project. The XFree86 project changed its licensing approach to one incompatible with many customer’s requirements and failed to respond to the needs of many users; this led to the founding of another project that replaced it. Of course, if you are the only user of an OSS/FS project, it may not be worth becoming the lead of a “follow-on” project -- but you at least have the right to do so. An OSS/FS project cannot work too far against the interests of its users, because the users can wrest control away from those who try.