Richard Stallman’s model for how to make money with Free Software (that is, software under the GNU GPL) has always been developer-centric: he regards everyone who gets between the developer and the user as mere middlemen. In the Free Software business model, a developer can earn money by supplying documentation, by supporting a product (that is, by answering questions about problems with its use), by fixing it so that it works the way the user wants it to, and by other services aimed at the software user.
In the previous chapter we had a look at some of the forms those businesses can take when they are based on the platform itself, that is, the operating system and the hardware on which it runs. This is a broad field with new competitors entering all the time. Beyond the platform, an entrepreneur can concentrate either on tools or applications, and thus focus both development and marketing to make these efforts more manageable. The trick is figuring out how to build a business when the basic asset, the source code of the product, may be freely taken, changed, and distributed by anyone. As we will see in this chapter, it is possible to work from straight GPL software and build a business, but the more usual models involve some variation from GPL licensing.
For years construction companies have dealt with different markets — those requiring union labor and those not requiring it — by splitting into two components, one unionized and one open-shop. In the Open Source applications world, a number of companies are using the same approach with licensing.
Most of the original Open Source projects are tools aimed at developers, rather than applications aimed at the general user. For this reason, the best track records for products and firms are among the tools. Ajuba Solutions (http://ajubasolutions.com/), formerly Scriptics Corporation, is an example of an enterprise built on an established Open Source tool, Tcl/Tk, rather than founded on a new technology. Tcl/Tk consists of a scripting language (Tool Control Language) and an associated Tool Kit (Tk); over half a million developers use it, including some in large enterprises using it for mission-critical work. John Ousterhout tended it for six years at Berkeley, where it was ported across the various UNIX platforms. In need of funding to port to Windows and the Macintosh, the project moved in 1994 to Sun Microsystems, which supported development for a further three-and-a-half years. In 1998 Sun spun off the project as Scriptics Corporation, still under Ousterhout’s leadership; he intended to develop a complete product around the technology.
For Open Source technologies to increase their audience beyond the faithful and highly technical few, they must consider other users. Generally a book about the technology comes first, followed by training, packaging, and support. Development tools and add-ons come next, followed by extensions. These all serve to make it increasingly easy for others to use the new technology. The question is, who will fund these activities? Even if it is ultimately to be the users, there needs to be a means of organizing the financial and technical resources to do the work.
Ajuba’s approach is to continue Tcl/Tk as an Open Source product, while adding proprietary extensions to it (such as Ajuba2, formerly Scriptics Connect) and selling those. Additional revenues come from training, support, consulting services, and proprietary tools (TclPro) that make working with Tcl/Tk easier. The trick is to make sure Tcl/Tk not only remains a popular tool among developers, but increases its use among them. The proprietary extensions are one way of achieving that goal, but specifically Open Source means must be used as well, so Scriptics uses its own resources to improve the free product. Ajuba intends to attract new users with the free product, and to remain the center of gravity of Tcl/Tk users by providing a Web site with the Tcl Resources Center, which is intended to be the most complete source of information about the product. Profits from the proprietary tools and extensions will fund the Open Source side of the enterprise.
The fact that Ajuba uses a BSD-style license makes coordinating across the business much easier than it would be under the GNU GPL. The Tcl/Tk license allows users to change and freely redistribute the product, but does not require the disclosure of source code. Ousterhout reckons that there is a substantial class of users who are not interested in the GNU GPL, and who are in fact leery of it. The possibility of forking keeps Ajuba focused on serving the interests of the Open Source users; they, in turn, are happy to turn over their improvements to the free product because, if these are adopted, their originators will no longer have to maintain these changes in their own copies of Tcl/Tk. Ajuba further improves Tcl/Tk by folding in general improvements originating in proprietary work; it is the specialized or niche improvements (extensions) that Ajuba withholds for proprietary use.
Organization of the Open Source Tcl/Tk project into a corporation has given it an important resource generally missing from Open Source projects: a plan for dealing with the market. For instance, because analysts originally yawned at claims that Tcl/Tk could provide 5 to 10 times faster development than C, C++, or Java, Scriptics shifted the focus to Tcl/Tk as a tool for integrating applications in the enterprise. It is interesting to note that the majority of downloads from the Scriptics Web site are for the Windows version of Tcl/Tk.
Licenses that Help Two Old Standards Go Commercial
Apache and sendmail are two ubiquitous programs that helped build the Internet. The Open Source Apache Web server is the foundation for the proprietary secure-server version from C2Net (http://www.c2net.com) called Stronghold. Covalent Technologies, Inc. (http://www.covalent.com) sells support plans for Apache and other products, and has also added SSL to Apache in a proprietary add-on called Raven. Apache itself comes with source code, but does not require modifiers of the code to pass on their changes to the source code. The Apache project itself continues to be guided by a cooperative group of developers; the founders of C2Net and Covalent come from this group.
The similar terms of the BSD licenses enabled sendmail’s originator to start a company both to furnish support and to provide proprietary add-ons (such as a graphical interface) to the product. Among other strategies, Sendmail, Inc. (http://www2.sendmail.com) will provide OEM versions and also encourage third-party products based on sendmail.
Larry Wall, the originator of the scripting language Perl, did not choose to found a company built on his technology. Instead, he is paid by O’Reilly & Associates to work on books about Perl and on any Perl-related project that interests him. There is, however, at least one company built on Perl, ActiveState Tool Corporation (http://www.activestate.com); like Scriptics it publishes both Open Source and proprietary software in support of its chosen technology.
This is not a case of an intruder grabbing an Open Source project away from its originator. Larry Wall is still very much the central figure of Perl, but several important Perl leaders are at ActiveState. These include the chiefs of the two variant versions of Perl on the Windows platform who later combined them under the OnePerl plan (see Chapter 7, "Complications of Open Source Licensing"). ActiveState publishes its own Perl products, both Open Source (like ActivePerl) and proprietary (PerlTools comes only in binary form). O’Reilly is an investor in ActiveState, and helped get the company started.
Since Perl runs on servers, the Windows versions are 32-bit, aimed at Windows NT. The ActivePerl project was originally funded by Microsoft to add Windows features to Perl; it is now wholly funded by ActiveState, which has added enhancements such as Unicode support. The product is freely downloadable; users can pay for a CD if they wish. The source code is included with the product. The license in this case is a special Community License (http://www.activestate.com/ActivePerl/docs/Perl-Win32/commlic.txt) that conforms to the requirements of the Artistic License. The notable limitation is that persons wishing to distribute a derivative of ActivePerl must apply to ActiveState for a license to do so; this is primarily to secure agreement from the distributor that ActiveState will be prominently mentioned in the derivative product.
ActivePerl provides ActiveState an increasing presence in the Windows server market, and generates some revenue from CD sales. Major revenue comes from consulting fees and from support programs such as PerlDirect, which provides subscribers with regular updates of the ActiveState Perl distribution and its extensions, along with a newsletter, support services, and a chance to participate in online discussions with leading Perl developers. The PerlDirect distributions are binary-only, and may be distributed only within the subscriber’s company.
Scriptics and ActiveState were founded on the basis of supporting and extending existing Open Source technologies. Going in the other direction, it is perfectly possible for an existing firm to begin an Open Source project as part of its corporate strategy. The product serves to advertise and promote the skills of the project sponsor; if the community accepts it and improves it, the company will save some of the development costs that it would otherwise spend on maintaining and improving the software. As a best case, the community and the company will produce a better and more useful product that everyone can use, including the firm that originated and released the Open Source product.
Digital Creations is known for the Open Source application server it originated. Called Zope (http://www.zope.org), this application server is attracting a variety of Open Source projects to extend it. It is a content management system that stores all the material in an object-oriented database (Zope is built on Python). As an application server, Zope is intended to be the Open Source answer to Cold Fusion, serving one or two million hits per day on a low-end machine.
Digital Creations had originally planned a strategy something like that of Capital Technologies: keep most of the technology proprietary and release some of it as Open Source. The firm attracted attention at the end of 1998 when they announced that their Zope server would be released as Open Source software under their Zope Public License (ZPL, a BSD-type license) and that their venture funding was behind the move. Zope is fortunate to have a funder who understands the Open Source world; in fact, the Digital Creations founder, Paul Everitt, met the VC on a Python Usenet list.
Everitt has given many reasons for making Zope Open Source. Among them:
* Rapid market penetration, which would otherwise be unobtainable without a large marketing budget; there is no financial value in a good package that very few use.
* The present Zope technology (or any proprietary technology) will be overtaken by competitors anyway; a vendor must rapidly and continuously improve and evolve the product. Creativity, not technology, is the asset.
* Loyal users provide free and convincing word-of-mouth publicity.
* Making Zope Open Source and talking about it will ride the coattails of Red Hat and the Open Source buzz; in turn, Digital Creations will ride the coattails of Zope.
* A widely used product will enhance the reputation of Digital Creations; its Open Source nature will give users the confidence to try it because the code continues, even if Digital Creations should disappear.
* Digital Creations’ consulting business is based entirely on the Zope platform; the fastest way to get extensive testing and thus higher-quality software is to give it away with source code.
* If the Open Source community likes Zope, they will contribute improvements faster than Digital Creations could make them, and these improvements will be more closely aligned with what the market wants.
* As originators and maintainers of the Zope project, Digital Creations is the obvious source for custom and consulting work, just as Cygnus has built its business on the GNU tools.
* Open Source effectively builds a pool of outside experts who not only provide development and maintenance at low cost to Digital Creations, but also show from their attitudes and quality of contributions which ones would make the best new hires as the firm expands.
Digital Creations began by providing a viable applications server to the community, and sponsoring the community effort to maintain and improve it. Response has been good, with developers providing not only patches, but also new features and projects. This outside help has lowered the amount of effort Digital Creations has had to put into porting Zope on different platforms and databases. An additional benefit to Digital Creations is that the Zope project occupies the space for an Open Source Python-based applications server; so long as Digital Creations manages the project to satisfy community expectations, there will be no motivation for developers to fork the project and begin a competitor. Thanks to the BSD-style license, code from a competing Open Source project could be folded back into Zope.
Zope forms the basis of Digital Creations’ business by providing a pool of potential clients. These clients come to Digital Creations because they want larger Zope-based Web sites and/or want their projects done as quickly and efficiently as possible. Such projects call for consulting services rather than another piece of software, but because consultants have favorite tools that they have developed for their work, it is logical that Zope comes to assignments armed with ZEO (Zope Enterprise Option), the answer to high-end problems. Unlike Zope, ZEO is not Open Source but "source inspectable"; source code is available to clients, but they may pass along neither it nor the binary code. Because ZEO is essentially a tool for Digital Creations’ consulting engagements, it comes with 40 hours of consulting; work beyond that is billable.
ZEO Is Going Open Source, Too
Management at Digital Creations like Open Source so much that they are turning their proprietary upsell product into an Open Source project. Believing that improving Zope by adding ZEO is more important to their long-term business success than keeping ZEO to themselves, Digital Creations is now in the process of moving ZEO from proprietary to Open Source status. As is common with new Open Source projects they are at first working privately with selected partners. Once they judge that the code is ready, they will turn it into an Open Source project, and eventually merge the ZEO code into Zope.
As part of its market penetration strategy, Digital Creations is encouraging businesses built upon Zope; it began by listing providers of hosting services for Zope, and has recently added a long page of "Zope Solution Providers": essentially competitors with Digital Creations in providing consulting services associated with building and operating Zope-based Web sites. The BSD-style Zope Public License makes it possible for these businesses to make money from Zope, and even to make their changes to the code proprietary (or at least to keep it from their clients if they choose this method of locking them in). It is in the interest of these providers to send back at least patches if not improvements to the Zope code tree to build a better product, and so that they will not have to continually update these fixes as new releases of Zope appear.
Digital Creations believes it can better encourage these Zope-based businesses by keeping a distance between its own Web page and that of the Zope project. The only mention of the company on the Zope project site is as one of the many Solutions Providers. The Digital Creations site, on the other hand, takes credit for having developed Zope, placed it in Open Source, and for managing the Open Source project. It also offers ZEO, which is not mentioned on the Zope project site. Paul Everitt regards this separation as "the perfect distance between the two": if it were too close, Zope would be seen as a shill for Digital Creations; if the connection were more distant, people would suspect Zope of not being viable in the long term. Digital Creations is making all this work together to build a business.
If Zope aims to fill the Python-based Open Source application server space, Enhydra (http://enhydra.org) intends to be the Open Source Java/XML-based application server. In contrast to the distance cultivated by Digital Creations, Lutris Technologies (http://www.lutris.com) features prominently on the Enhydra project site’s front page, besides being listed among those providing services for Enhydra. Lutris believes the close association is reassuring for Enhydra users, demonstrating that there are paid resources and developers devoted to keeping the product current. Lutris also encourages associated Enhydra businesses by offering marketing help, currently a set of Enhydra logos, but with the promise of more material to help promote the product.
The Lutris upsell to Enhydra is more open than ZEO; this is Enhydra Enterprise, which adds high-end features to the basic Enhydra, and which is distributed under a derivative of the Mozilla Public License called the Enhydra Public License (EPL). Unlike the BSD license, the MozPL prevents the distribution of binary-only copies of Enhydra Enterprise, requires distribution of source code for modifications, and enables add-on products to keep their source code to themselves, provided they use only the published APIs of Enhydra Enterprise. Lutris chose the MozPL model because Java binds code too closely together for it to be perfectly clear which contributions should come under the GPL and which need not. At this time Lutris has no plans for binary-only add-ons; there may eventually be some for vertical markets.
We can see that it is possible to base businesses on the strict GNU GPL by offering services, or on other Open Source licenses by offering a combination of services and proprietary software. BitMover, with its new license and business model, shows that we are only beginning to try out the many possibilities.
BitMover will soon offer BitKeeper (http://www.bitkeeper.com), a system designed to manage source code submitted by multiple developers in multiple locations. It is particularly apt for the distributed nature of Open Source projects, or for other large development efforts.
The originators say that Linus Torvalds has said he will adopt BitKeeper for the management of the Linux kernel, "If it’s the best," and they explain any delays in development as necessary to meet that standard. They believe that adoption by Torvalds would bring the rest of the Open Source community to use the product. Linux kernel source control must deal with the many branches of the code: beneath the two main branches to the source tree are the "stable release" and the "development release," and under the second are any number of provisory or experimental branches for trying out different approaches.
When BitKeeper is released, any Open Source project will be able to use it for free, and to freely distribute it. The restrictions beyond this level are quite interesting. First, while the source code may be modified by a user, it may not be distributed unless the new version passes a regression test using a free testing tool from BitMover. There is nothing unusual about such restrictions in Open Source licensing: the Apache license says that users may distribute a modified version of Apache, but may not call it Apache. The Perl Artistic License forbids the use of the Perl name on modifications that are not designed to coexist peacefully with existing Perl installations on users’ systems.
It is the second restriction that draws the line between the worlds of Open Source and proprietary software. BitKeeper produces a source change log, which is automatically posted on the Web so that the developers can easily keep an eye on it. This is a useful feature for any multideveloper software project. Open Source projects can hardly object to a public posting of changes, but proprietary developers will most likely object, even though the log does not post the actual source code being worked on. Developers who don’t want the change log publicly posted on the Web (at the BitMover Web site), can buy a license for a special version of the software (BitKeeper/Pro) so that they will be able to keep the log on an internal server, or even suppress it altogether.
The BitKeeper model and license offer the Open Source community the full use of the tool; no feature has been crippled and it is not an older version of the software. Besides the requirement to regression-test modifications, the only restriction is that a useful feature be left undisturbed. The only developers likely to object are those working on proprietary software, so they must pay for their request to have the tool modified. By putting its finger on the one feature that a proprietary developer could object to, and by making that feature a benefit for Open Source developers, BitMover avoids the usual vague attempts to tell users that they must pay if they are using a free product "commercially" or "in business," or that certain software is only for "nonprofit use." As clever as this model is, it seems to have one limitation: can another product come up with a feature that benefits Open Source use but is a liability for non-Open Source users?
The payoff for BitMover, however, is clear. As a free product it may gain wide use among Open Source projects; if many developers become users, it will be easier to sell the commercial version to corporate development operations.
The Open Source model produces creative answers to many problems, whether in code development or business. In the next chapter we will look at the proprietary software world. If we regard Open Source as the original way of writing and distributing software, and proprietary software as an intrusion into and confinement of that original way, we can see where its limitations come from, and what effect the return of Open Source will have upon them.
Next chapter: The Proprietary Software Business: New Opportunities . . . and Pressures
Table of Contents
Copyright © 2000 by IDG Books Worldwide, Inc. Published under IDG Books Worldwide, Inc. Open Content License.