Netscape Source Code as Netscape Product

11 November 1997
Revision 0.7

Disclaimer: This document represents my personal opinions only, and not the official position of the Netscape government sales group (or of Netscape as a whole, for that matter).

Introduction

Netscape today faces several separate but interconnected challenges, among them I believe these challenges are interconnected for two reasons.  First, most if not all of them are functions of Netscape's constrained resources: not enough people, money, or time to do everything that needs doing.  Second, I believe that we have possible strategies available to us that may help address all these issues together; in particular, there is one possible strategy suggested in part by Netscape's history:

When Netscape first made Navigator available for unrestricted download over the Internet, many saw this as flying in the face of conventional wisdom for the commercial software business, and questioned how we could possibly make money "giving our software away".  Now of course this strategy is seen in retrospect as a successful innovation that was a key factor (if not the key factor) in Netscape's rapid growth, and rare is the software company today that does not emulate our strategy in one way or another.  Among other things, this provokes the following question: What if we were to repeat this scenario, only this time with source code?

Starting with the business problems we currently face, I explore in this paper the case for distributing Netscape source code very much as we do binary executables today, and I propose roughly analogous licensing and pricing models for source code distribution, including no-cost (or very low-cost) source code licensing for noncommercial use.  I also consider common objections to distributing source code and attempt to respond to them.  Finally, I present some possible actions Netscape could undertake as part of studying and/or implementing such a strategy, including in particular distributing one of the upcoming Gemini developer releases with full source code and associated licensing terms as a pilot test of the strategy proposed in this paper.

Products as source code

Netscape as a company is now strongly committed to building its future products using three core cross-platform technologies: HTML, JavaScript, and Java.  These share the property that applications written using them are deployed not as opaque executables but rather in a form that is identical to their source code (in the case of HTML and JavaScript) or from which the source code can be relatively easily derived (in the case of Java); thus in effect releasing HTML/JavaScript/Java-based products is tantamount to releasing a large body of Netscape source code to the world.

A problem or an opportunity?

Some people see this as a major problem, and wonder how we can compensate for it (for example, by "obfuscating" the distributed Java code) and thus maintain the present state of affairs where commercial software like Netscape's is normally distributed in run-time form only.  On the other hand, I am interested in whether this issue of "product as source code" is not only not a problem, but rather may present a significant opportunity for Netscape; this is especially the case if we also consider at the same time many of the other issues Netscape must address: creating more products to sell, doing more sustaining engineering to fix bugs and make incremental product improvements, appealing to third-party developers, and so on.

Let's start with Netscape's business model and how it might be improved and adapted if we decided to distribute source code as a conscious and deliberate strategy.

The business of Netscape

Netscape's purpose is to help individuals and organizations harness the power of the Internet; Netscape's characteristic approach to fulfilling that purpose is to leverage the power of the Internet ourselves: in software distribution, in QA, in marketing, and so on; I'll come back to these topics later.  But Netscape is specifically in business (as Jim Barksdale says) to get customers and keep them.  Customers are organizations or individuals who see value in the products and services that we provide, and who pay us good money in order to obtain them.  We get customers by convincing people that we can provide something of value to them and persuading them to give us money in exchange for that value.  We keep customers by providing them not just one-time but continuing value, sufficient that they will continue to give us money in exchange for the value they continue to receive.

For customers, value is not necessarily associated with particular features of a product.  (And in fact, products with the same features offered by two different companies may have different value for customers in each case.)  More generally, a product has value for customers to the extent that it helps them solve problems; the more problems it can help them solve or the more important the problem it helps them solve, the more value the product has.  Customers may solve these problems with the help of the product's actual features (as Netscape Navigator originally helped solve the problem of accessing the Internet without complicated utilities) or they may solve their problems with the help of other product attributes (as Netscape's brand name and market dominance help solve the problem of making a "safe" buying decision).

Over time Netscape has attempted to add additional value to its product line by adding new features to existing products (e.g., mail and news support in Navigator and then Communicator), adding new products (e.g., the SuiteSpot servers), adding new ways to use the existing products (e.g., Netcenter), and so on.  For Netscape to continue to grow as a company faster than the overall market, we need to find new ways to provide value to customers, and new ways to convert that value into money.

Competing with Microsoft

But Microsoft also can add new features, new products, and new ways to use them, and it has much greater resources with which to do this.  Netscape needs not only to offer particular product value earlier than Microsoft, but also needs to both match (or at least come close to) the value that Microsoft's resources create for its own products, and at the same time create value for Netscape products and services in ways that Microsoft cannot easily duplicate, either in principle or at least without adversely affecting the value of other Microsoft products.  (An example of the former type of value is simply that Netscape is not Microsoft, and can thus help solve the problem of customers being dependent on Microsoft for all their information technology.  An example of the latter type of value is Netscape's cross-platform support, which helps customers solve the problem of preserving their investment in existing systems, and which Microsoft cannot fully duplicate without adversely affecting the relative value of its own products, particularly the latest versions of its operating system software.)

In essence competing with Microsoft means continually having to pursue temporary (at best) advantages in relative value deriving primarily from product features, combined with more strategic attempts to alter the competitive balance in ways which Microsoft is less prepared to cope with.  Netscape's initial strategy of distributing "free" software over the Internet was a successful attempt to change the rules in this way, one that gave Netscape at least a year's lead in the market and helped build a market position that allowed Netscape to survive in the market once Microsoft entered it.  It's therefore worth considering how we might change the rules once again.

Source code as a product

As noted above, Netscape's long-term product development strategy commits us to shipping software products that are increasingly "source code-like"; however our long-term marketing and sales strategies have not yet changed to reflect this.  If this situation continues then we run the risk of encountering all the problems that many predict shipping source code will cause, while not deriving any of the benefits that others (including myself) claim we could enjoy.

Let's therefore consider (as a thought experiment if nothing else) if Netscape were officially to ship source code to its products, and were to do so on terms comparable to those on which we currently distribute binaries (e.g., Internet distribution, free evaluation use, free use for educational institutions, etc.).  Leaving the finer points for later, such a strategy must at a minimum address two issues: How does distributing source code create value for customers, and how can Netscape convert that value into revenue and profits (i.e., money)?

Note that by "source code" for a given application I mean the underlying programming language statements (and related information, e.g., make files, error message files, etc.) which can be read by humans, modified to make changes and additions, and then used to build a fully functional version of the application, or another derived application reusing some or all of the same source code.  For purposes of this discussion we assume that for a given product (say Communicator) we would distribute all relevant source code. (In actual practice this may not be possible in all cases, as discussed below; for example, we might distribute some components of a product in binary form only, or not separately distribute certain components at all.  We would also likely follow an incremental strategy in releasing source code, starting with particular products or particular components of those products, and adding other products and components as time went on.)

What value does source code have for customers?

Much software has traditionally been distributed in source code form, and there are several commonly-accepted ways in which having source code for a product can directly increase the value of that product for a customer by helping them solve a number of problems: Distributing source code for a product can also more indirectly increase the product's value to a customer: These ways to increase value are again quite familar to anyone acquainted with products such as Linux, GNU Emacs, or Apache that are normally distributed with source code (or for which source code is available separately).  Together they help to make products whole products, in the sense used by Geoffrey Moore (in Crossing the Chasm and Inside the Tornado) and others: products accompanied with all the additional things necessary to ensure that the value experienced by the customer matches the value promised by the vendor.  These things include support, documentation, training, third-party consulting and system integration, a thriving developer community to use the product in innovative ways and create add-ons to the product, a set of de jure or de facto standards upon which the vendor and others can build, and so on.

This is exactly where Microsoft's greater resources and experience serve it well; to compete successfully with Microsoft as time goes on, Netscape must not only create products that are more functional than Microsoft's in a generic sense, but must also find ways to approach or match Microsoft's whole product value, ways that do not require Netscape to take on the entire burden of doing so itself (since our own resources will never equal Microsoft's).  However, for Netscape as a commercial company it is not enough just to increase the value of our products; we must also find sustainable ways to have customers reflect that value back to Netscape in the form of increased revenues and profits; it's therefore to that subject I now turn.

How can Netscape best convert the value of source code into money?

Today the conventional way to get revenue in exchange for the value of a software product is to sell the customer the right to use the software product as opposed to selling them actual ownership of the product (as they might own a physical object); even a customer buying shrinkwrapped software sold in stores is technically buying a right to use license rather than possession of the software itself.  However vendors concerned about software piracy traditionally assumed that possessing a copy of the software was tantamount to using it, and that a user who got a copy of the software without paying for it represented revenue permanently lost to the vendor.

While retaining the idea of payment in exchange for the right to use software, Netscape is instead committed to a business model that assumes that anyone can easily get a copy of our software without paying for it first; Netscape's goal is then to convert existing users into paying customers or otherwise have value received by users returned in some way to Netscape as increased revenue and profits.  Netscape's history shows that this is a quite reasonable business model for the business market (in which organizations are motivated to comply with the legal terms of licenses) and is a workable model for the consumer market as well (in which many people will pay if for no other reason than the convenience of having physical media).

Netscape's business model also recognizes a third major market, namely educational institutions, in which users are not expected to pay anything at all for the right to use software; value provided to users in this market is either paid for on a delayed basis (i.e., when students move from school to work and purchase products they've previously found valuable) or acts to create added value for other users who do pay for it (e.g., when the added market share from educational users adds to the ubiquity of the product, increasing its value to customers looking for a "safe" choice).

Finally, Netscape distinguishes between at least two segments of the business market: the enterprise market, where software is used mainly internally and is typically priced on a per-user basis, and the content/service provider market, where the software is mainly deployed externally and where somewhat different pricing schemes are used, to reflect the fact that it can be more difficult to define "number of users" in this environment (for example, when providers do "speculative distribution").

There seems to be no a priori reason why a business model analogous to our current one could not be made to work with source code as well.  The exchange of money for value would again be based not on mere possession of the code, but rather on a right to use, which for source code means the right to create and distribute derivative works based on the original source.  In other words, Netscape would make its source code available for download in exactly the same way that we distribute binaries today; thus anyone wishing to have a copy of Netscape source code could obtain one without any special prior arrangements (e.g., signing a non-disclosure agreement and/or paying a licensing fee).  Formal licensing and payment (if appropriate) would kick in only at the point that the customer used the source code to create their own derivative work.

Licensing and pricing for source code

The general licensing/pricing model for source code would be that source code used by customers to create derivative works used or sold commercially would be licensed and priced so as to produce direct revenue to Netscape; for derivative works used or distributed noncommercially Netscape would receive  revenue only indirectly, as discussed below.  The difference between commercial and non-commercial use is not necessarily straightforward; in particular, using Netscape source code to create "freeware" (i.e., software available at no cost) should not necessarily count as noncommercial use, especially if it is done by a commercial (i.e., for-profit) concern or by customers such as government agencies.  Ultimately Netscape itself would be the judge of what constitutes commercial versus noncommercial use of our source code, just as today we decide which customers qualify for educational or charitable discounts on our products and which do not.

Other suggested general principles in licensing and pricing source are as follows; note that when I refer to "licensing source code" below I really mean "licensing the right to create and distribute derivative works based on source code":

The specific licensing models for the various markets would be analogous to the corresponding licensing models for binary code.  (Note that this is only a first cut at more specific models; there are many cases that would quite likely have to be treated specially.) Of course, distributing source code is a nice thing in and of itself, and for Netscape considered as "the Internet company" is consistent with traditional Internet cultural norms of sharing information as widely and freely as possible; it is also consistent with Netscape's traditional approach of leveraging the power of the Internet and low-cost distribution in our own business.  Such a strategy would no doubt be welcomed by many users, and may gain us favorable attention in at least some segments of our market; it could also produce new incremental revenue we would not otherwise have received.  However the acid test for a strategy of source code distribution would be how well it helps Netscape compete and win in the marketplace against our competitors, most notably Microsoft.

How does distributing source code help Netscape compete against Microsoft?

As noted above, any proposed new strategy should help Netscape achieve at least two overall goals: A strategy based on distributing source code helps create additional whole product value for customers as described above, namely by furthering stimulating a community of writers, trainers, consultants, system integrators, and software developers who can write documentation, create training materials, provide technical support, and create more systems and products based on Netscape technology.  The primary challenge for Netscape here would be to find ways to capture that increased value as increased revenue; some of the possible ways to do this are discussed in the previous section.

Could Microsoft alter its strategy so as to duplicate the value that this strategy might create for Netscape, or otherwise blunt the impact of this strategy on Microsoft?  At least two possible Microsoft counter-strategies present themselves immediately:

First, Microsoft could attempt to match Netscape's strategy exactly, namely by releasing source code for some or all of its own products.  (To those who claim that Microsoft would never do this, I respond that there is apparently only one ironclad rule at Microsoft: that Microsoft must win.  Microsoft has already shown in its Internet strategy how willing and able it is to abandon traditional strategies in order to protect its competitive position.)  However, this straightforward "anything you can do, I can do better" strategy has at least the following disadvantages for Microsoft relative to Netscape:

A probably more effective counter-strategy to Netscape's releasing source code would echo Microsoft's strategy vis-a-vis Java: embrace the technology (to some degree) but coopt it to Microsoft purposes by extending and using it in incompatible Microsoft-specific ways.  For example, Microsoft could simply take Netscape source code, extend, modify, or otherwise use it to create new products that were better than Netscape's own, and then give away or sell those products away to all and sundry.  (Remember, money is no object here: Microsoft could devote a hundred million dollars a year to doing this and still have minimal impact on its own profits.  Also, even given the recent activity by the U.S. Department of Justice, for purposes of defensive planning it is best to assume that Microsoft will be free to pursue almost any strategy it wants to against Netscape with minimal concern for anti-trust or any other legal restrictions.)

This counter-strategy has less downside for Microsoft and it is worth considering how Netscape might defend against it.  Netscape could try to prevent Microsoft from licensing its source code, could restrict the licensing terms to protect against Microsoft or anyone else creating incompatible competing products, or could structure the licensing terms such that Microsoft would have to pay Netscape as much money as Netscape would have realized by distributing the source code and resulting products itself.  However Microsoft can afford to hire the best lawyers on the planet, and again for planning purposes we should assume that they could find appropriate loopholes no matter what the licensing agreement said.

However there are still disadvantages to this counter-strategy for Microsoft (and relative advantages to Netscape):

As implied above, this proposed Netscape strategy based on source code distribution cannot guarantee victory in the market battle with Microsoft; it cannot even guarantee Netscape's survival.  However it is consistent with the overall history and likely future direction of the Internet/intranet market, is consistent with Netscape's own history, strategy, and traditions, and if executed successfully holds the potential to increase Netscape's importance to the market, drive increased Netscape revenues and profits, and buy needed breathing room for Netscape to achieve critical mass as an ongoing commercial company.

Objections

The previous sections were devoted to building a convincing argument for Netscape adopting a new strategy based on public distribution of the source code for its various products.  This section is devoted to ripping that argument to shreds, in the ultimate faith that the argument can withstand the various objections that people might bring against it.

"Wouldn't we be giving away our 'crown jewels'?"

Software companies often refer to their source code as the "crown jewels", implying that it is a precious resource that must be protected at all costs from anyone outside the company who would seek to obtain it or (mis)use it.  Thus companies release source code only in very special situations, and do so only when accompanied with an array of legal arrangements, including non-disclosure agreements and tightly-worded contracts.

But arguably possessing source code in and of itself is irrelevant.  Source code acquires true commercial value only if you can use it to create products and services that you sell for money, and you can typically do this successfully only in the context of a company with a known brand name and a sustainable market position.  (In other words, if I had the source code to Windows, it wouldn't make me Bill Gates.)  Similarly, releasing Netscape source code would not necessarily mean that other companies (including Microsoft) could duplicate Netscape's successes or even adversely affect Netscape's business.  Those successes are a result of much more than our source code; other factors include the celebrity of and trust placed in Netscape's brand name, the good will engendered by our liberal distribution and evaluation policies, the effectiveness of our sales and distribution channels, and so on.  Those factors could still be very much influenced by us, even in the absence of "complete control" for the source code itself.

A related argument is that our source code has so much value that we can and should charge a very high price to anyone wishing to license it.  In practice this policy can keep us from exploiting many possible market opportunities.  Suppose that a company wants to use our source code as the basis for a product to be sold into a limited market, a market so limited that it is not cost-effective for Netscape itself to address it.  However it may be cost-effective for the third party company to address this market, perhaps because the company can offer other (and relatively more lucrative) products and services tied to the Netscape-based product.  Why shouldn't we simply license our source code to such a company for a relatively modest fee, commensurate with the size of the opportunity, and thereby realize incremental revenue that we wouldn't otherwise have?  (I didn't just make up this example, incidentally; I have dealt with third parties who wanted to do exactly this for specific government market opportunities.)

One possible objection to Netscape licensing source code at low cost is that a third-party company creating derivative works would need support from Netscape developers to do its work, and that because these people are a limited resource we must in effect ration their use by setting the price of source code artificially high.  But developers experienced in working with Netscape source code are a scarce resource mainly because we do not generally license source code in the first place.  If we were to license our source code more liberally, especially if we were to license it for noncommercial use, then the pool of knowledgeable developers would increase and this problem of limited developer resources would to a large degree take care of itself.

"Wouldn't people just use our code and our expertise without paying for it?"

If Netscape were to release our source code, how would we protect against people getting a "free ride", i.e., using our code (and, by implication, the expertise embodied within it) to create their own products, and not compensating us in any way?  This is analogous to the original concerns about distributing our software on the Internet (i.e., how could we prevent "software piracy"?), and these new concerns can be addressed in similar ways.

Let's first consider noncommercial use (suitably defined); this is analogous to academic use and home use in Netscape's current binary distribution strategy.  As it's turned out, Netscape has arguably made much more money by "giving away" its software in these cases than it would have made by attempting to charge for each and every copy.  This is mainly because allowing such "free" use gave Netscape a very large market share within a very short period of time; that large market share in turn allowed us to charge commercial companies for licenses (because in many cases their users already had Navigator installed) as well as opened up new sources of revenue such as web site advertising (because so many users came to Netscape's site).

Similar dynamics could and no doubt would operate in the event that Netscape allowed noncommercial use of its source code to create derivative works.  Some noncommercial use would consist simply of creating fixes to bugs in Netscape software or porting Netscape software to operating system and hardware platforms we do not currently support; this type of use would directly benefit Netscape (and is the sort of thing we would otherwise have to pay money to someone to do).  Other use might consist of creating add-ons to our products by extending our source code; although this type of use might not result in direct revenue to Netscape, nonetheless it could and would indirectly benefit Netscape by making our product platform more valuable overall.  In these cases Netscape might choose to "take back" the new and improved source code by making it part of our own source code base; noncommercial licenses for our source might contain language giving us the right to do so (while still giving the original authors the right to create and distribute their changed code at no charge).

The only types of noncommercial uses which might be detrimental to Netscape's interests are where people attempt to use our source code to create and distribute substantially similar but competing products as freeware (e.g., "Norm's No-cost Navigator").  This is not necessarily a concern, since it is arguable whether this would in fact result in Netscape losing any revenue: commercial customers would most likely not use such freeware in lieu of paying Netscape for the original products, and home users who actually pay for Netscape software now would still be likely to buy shrinkwrapped Netscape products in retail stores as opposed to using freeware they would have to download.  However if we do have any concerns about potential harm to Netscape, we could control such undesired use through appropriate license terms, as discussed above.

Commercial use is even more controllable than noncommercial use, since it is almost always done in the context of a written contract (even if this is as simple as a purchase order) and a corresponding enforceable license agreement.  This control extends not only to use of the source code itself, but also to any techniques embodied within it for which Netscape might claim intellectual property rights through patents.  (This is independent of whether or not you consider software patents to be a good or bad idea in the first place.)

"How is this really different from what the GNU project tried to do?"

Traditionally a hard-and-fast distinction has been made between commercial software companies which do not release source code and nonprofit projects such as the GNU and Linux initiatives which do; if Netscape were to distribute source code, especially if we were to allow noncommercial creation and distribution of derivative works, many people would likely assume that our business model in doing so must be more like a non-profit venture like GNU or Linux than a for-profit venture like a conventional software company.  It's therefore worth considering in what ways this proposal is similar to what was attempted in the GNU and Linux projects, and in what ways it is very different; here we consider the GNU project primarily since the Linux project was to a large degree modeled after it, especially in its use of similar licensing terms.

As originally envisioned in Richard Stallman's "GNU Manifesto", the GNU project had at least three goals:

I think it is fair to say that the GNU project and related projects such as the Linux initiative have succeeded pretty well in meeting the first two goals, but have failed utterly in meeting the third.  There is at least one commercial company (Cygnus Solutions) based on the GNU business model (pay for development and support of software, but not for the underlying source code considered as intellectual property); however it has not been that successful compared to traditional software companies (including newer companies like Netscape), and apparently it has inspired few (if any) emulators.  Other companies (including Caldera and Red Hat Software) have made a business out of integrating and shipping Linux distributions, but again these companies are relatively small and are not really major players in the commercial software business.

Why is this?  The simplest explanation is that in a (mostly) capitalist economy people do not want software companies to have the  economics of relatively low-margin professional services companies like Arthur Andersen or EDS, they want software companies to have the economics of relatively high-margin software vendors like Microsoft or Oracle.  "People" here includes the entrepreneurs who found software companies, the venture capitalists who fund them, the shareholders who buy and hold stock in them, the salespeople who sell for them, and (arguably) the software developers who create products for them.  (Actually, whether software developers would really prefer the conventional model or the GNU model is to a large degree a moot point; because of the success of conventional software companies versus Cygnus-style software companies, the vast majority of commercial software development employment opportunities are with companies following the conventional model.)

I am not therefore proposing that Netscape adopt the GNU model in the area where it is failed; I assume that Netscape does and should "own" its source code in the sense of having and asserting valid intellectual property rights to it, including copyright in particular, and the business models I propose are based on charging customers for the right to use that intellectual property in various ways, in particular to create derivative works based on it.  In doing this we could charge whatever amount the market will bear, and in principle Netscape could have just as high margins in following this strategy as we do with our present strategy.

However at the same time the successes of the GNU and Linux projects are instructive in various ways concerning the potential success of the proposed source code strategy for Netscape:

In general the GNU/Linux way of doing software development and distribution holds many other lessons that could be useful to Netscape in pursuing in a strategy of source code licensing and distribution (see below for another example), and to a large degree the business model I am proposing can be seen as a deliberate hybrid of GNU/Linux practice and traditional commercial practice.  If GNU and Linux are considered to be examples of pure socialism (or communism or anarchy), and if Microsoft, Oracle, etc., are considered to be examples of pure capitalism, then in a sense the strategy in this paper represents an example of a mixed economy in which for-profit and non-profit sectors could coexist and cooperate, with each benefiting the other.

"What about things in the source that might reflect badly on us?"

We might be concerned with releasing source code for fear of inadvertently exposing material which might embarrass Netscape in some way if someone were to come across it.  Examples include bugs both minor and major, security flaws, and embarassing comments by developers; the latter could potentially include comments disparaging the code itself (e.g., "what a brain-dead hack"), product quality ("fix #1,000,001 for this turkey"),  or particular customers ("patch for the idiots at Acme Widgets") as well as the standard "seven dirty words" and other language not suitable for material intended to be in universal public distribution.

For bugs and security flaws we want public visibility, in the sense of people discovering problems and perhaps even identifying fixes to them; in this case short-term embarassment is worth it in return both for higher quality code and (just as important) the public perception that Netscape takes fixing bugs and security problems seriously, and is willing to open its source code to public inspection for others to investigate.  This would be in essence an extension of the current "bugs bounty" program for security flaws, which overall has been a plus for Netscape.

As for embarassing comments and the like, the most straightforward approach to address this would be to have developers understand that they were "writing for publication" and that each and every line of their code would likely be viewed both by customers and (even more important) by their peers in the developer community.  Within the context of a full source code strategy as outlined above, we could no longer treat source code as an internal-only matter, but would have to exercise just as much care as we (ideally should) exercise with released binaries and documentation.  This might require extra editing steps and code reviews, greater adherence to consistent formatting conventions (at least within particular sets of modules), and related actions.

"What about source code for technology we include from others?"

Many of Netscape's products incorporate technology from other companies, licensed in either source or binary form; how would we handle such technology in the context of an overall strategy of distributing source code?  This depends on the particular licensing terms that have been or could be negotiated with the technology supplier.

The most common case, at least initially, will be that our license with the technology supplier constrains us to shipping only the binary form of their code, and only embedded in the binary form of a Netscape product.   In this case we might still be able to supply our own source code for most of a product, as long as we "wrapped" the supplier's code in a binary component (e.g., a static or shared library) that could be called from our own code and statically or dynamically linked into other components compiled from our source code.  (We could use our own interfaces as the API between our source code and the binary component, not the supplier's interfaces; this would address the case where the supplier's interfaces were not publicly released or releasable, and would also avoid competing with the supplier's own products if they sold them in the form of a toolkit.)

In some cases the supplied technology would already be or could be encapsulated in a wholly separate binary component intended to be accessed by a public API; good examples of this today are Navigator plug-ins bundled and shipped with Communicator (e.g., the Cosmos plug-in for VRML).  Here we could possibly simply ship the separate binary component as we already do, and we would most likely have no restriction on releasing source code for our own components that make use of the supplier's component.

However in both the above cases the technology supplier (at least in the current environment) would almost certainly object to their components (even in binary form) being used to create derivative works, especially derivative works distributed noncommercially.  In those cases we would have to make it clear to customers that they would need to license those components separately from the original supplier, and the supplier would have to agree to this arrangement; otherwise we could release only our own source code, and then leave it up to the customer to find a substitute for the omitted components.

But assuming a clever and active developer community working with Netscape source code, this would quite possibly lead to the creation of substitute technology for the original supplier's technology, a substitute that would almost certainly be available under more favorable licensing terms.  Netscape could then potentially adopt the substitute technology instead, or at a minimum could use its existence as negotiating leverage to seek more favorable terms from the original supplier.

In the longer term, if our own source code strategy proves to be a success, there may be technology suppliers willing to emulate it and release their own source code as part of our source code distribution, especially if appropriate licensing terms could be worked out and if we can show them that this is ultimately in their interest and not just in ours (and the customers), by providing them with new ways to make money as well.  This should be a major focus of the strategy, because (among other things) outside developers adding features to Netscape products could in turn become technology suppliers to Netscape, and we would need to ensure that they would share in the rewards of the business.

"What about things in our source code that expose future plans or proprietary techniques?"

Often source code contains material such as comments or incomplete or "hidden" code (e.g., new APIs not publicly exposed) that could possibly give competitors insight into our future plans; the code may also implement new and useful techniques which could enable our competitors to duplicate product attributes such as features and performance that we consider to be competitive advantages.  How can we distribute source code in the face of such concerns?

There are actually two general  types of information at issue here.  First is information which is in the original source code but which gets removed as part of the  process of creating a binary run-time for distribution; this includes comments, "#ifdef-ed" code which ends up being removed by the preprocessor, and symbol tables and related information that are typically stripped from the released binaries.  Second is information which remains, and by definition must remain, in the binary run-time once built, namely the actual machine instructions or byte codes (in the case of Java) which implement the program's functionality (whether documented or not).

Although we think of the first type of information as being removed as part of the conversion from source to binary form, there is no reason in principle why such information (or at least much of it) couldn't be removed as part of the process of creating a "sanitized" source distribution; for example, the released source could be preprocessed to remove #ifdef-ed code and all comments except those specially flagged for public release.  On the other hand, information that must remain in the binary run-time can be obscured but can never be completely hidden.  Our competitors are perfectly capable of disassembling our binary code today and will be just as capable of doing so as we use Java more extensively, whether it's obfuscated or not.  License prohibitions against reverse engineering are like laws against intercepting cellular phone calls: a rational person should assume that their private secrets are available to anyone willing to expend the (relatively small) effort to obtain them, and given that assumption they should modify their behavior accordingly.

This goes back to the point above about "writing for publication".  If we are really concerned about material and information we don't want publicly released, then we need development guidelines and review procedures to ensure that such material is not present in released code (or never gets in the code in the first place).  If we really want to exert intellectual property rights over techniques (as opposed to the actual code), then we need to do such things as filing patent applications before publishing the code in question. (Again, neither software patents nor trade secrets are needed as underpinnings for this proposed source code distribution strategy; I assume only that we have copyright protection for our source code, combined with license agreements to assist in enforcing that protection.)

There is a larger question about what is appropriate for Netscape to keep secret, and under what circumstances.  Arguably we should not be concerned about keeping secret general information about our long-term strategies or general  information about produce release schedules.  In the case of corporate strategy we actually want people to know this information, as it strengthens our marketing message to organizations concerned with strategic planning and making long-term commitments to vendors.  (Our problem is more often the opposite: that people typecast Netscape as a "browser company" and don't actually know that we have a real strategy.)  As for release schedules, these are roughly guessable by anyone looking at our beta releases and familar with past history and the overall scope of work.  (For example, historically Netscape has released new Navigator and Communicator releases roughly every 10 to 12 months; thus an outsider could make reasonable estimates, say to within a quarter, of release dates for Communicator 5.0 or even 6.0.)

There is information which we want to take reasonable measures to protect, for legal or competitive reasons; examples include information on revenue and profit figures (prior to public release), mergers and acquisitions being evaluated, strategic agreements being negotiated with other companies, large sales deals in progress, and so on.  However little if any of this information is reflected in the actual source code.

"What about export control issues?"

So far I've assumed that Netscape would have compete discretion over whether we wished to release its own source code or not, as well as over how much of that source we would choose to release.  However there is one key area, namely security-related and cryptographic code, where Netscape is and will almost certainly continue to be constrained in major ways regarding distribution of binary and source code; given recent activity in the U.S. Congress, it is even possible that those constraints will become even more restrictive than they are today.  It's therefore useful to review how much freedom of action we are likely to have in this area, and how that would affect any source code distribution strategy.

Under the current regulatory regime, Netscape is prohibited from exporting from the U.S. or Canada software that implements strong cryptography (e.g., using greater than a 40-bit symmetric encryption key).  Thus at a mininum Netscape would be prohibited from exporting source code that implemented such cryptography.  (However we could distribute such source code within the U.S. and Canada, at least for the present.)

However the restrictions are actually more onerous than that.  The U.S. government has traditionally refused to permit the export of products in which the supplied weak cryptography could be easily replaced with strong cryptographic implementations developed outside the U.S.  This is exactly why the source code for the SSL Reference Library (SSLRef) was considered to be an export-controlled item with controlled distribution, even though the source did not actually include any cryptographic code.  Therefore it's reasonable to conclude that even under the current regime Netscape would not be able to export source code to our security library.

It's also possible that the U.S. government may decide to impose further restrictions as part of recent attempts to regulate domestic use of cryptography within the U.S.  For example, it may be that Netscape will be prohibited in the future from shipping any product unless it implements a key escrow scheme of some type.  Assuming that the escrow scheme is enforced by the security library, we may be prohibited from distributing source code for the security library even within the U.S. and Canada, on the grounds that others could easily create a derivative work that disabled key escrow.

The ultimate question is where the U.S. government will "draw the line" in terms of attempting to exercise control over the use of cryptography by imposing restrictions on commercial software vendors.  Given that Netscape and other software vendors have only limited influence over the future of cryptography regulations, if Netscape decides to pursue a strategy based on source code distribution the best that we can do is simply to distribute source code to the maximum extent permitted by relevant laws and regulations both in the U.S. and worldwide.

"Wouldn't this lead to fragmentation of the market, as with Unix?"

Suppose anyone could modify Netscape source code as they wished and in essence create in a new "version" of any Netscape product; wouldn't we be in danger of seeing our market fragmented by the appearance of multiple incompatible and competing versions of products based on our source?  How could we prevent this "Unixification" of our market?

Part of the answer might be in source code license terms prohibiting licensees (commercial or noncommercial) from breaking backwards compatibility and interoperability and introducing new and incompatible APIs.  However the ultimate solution to the problem lies in ensuring that the interests of all parties are aligned, and that preserving compatibility and interoperability is a major goal of everyone involved in creating products based on Netscape source.

Arguably the fragmentation of Unix occurred because the companies involved were not interested in Unix and Unix-based software per se; rather they were interested in selling computer hardware, and Unix was merely a convenient operating system to run on that hardware.  (See Mike Loukides's "Brief History of UNIX" for more on this view.)  In competing with other hardware vendors using Unix, there was no inherent aversion to changing the operating system in incompatible ways; in fact, companies had an active interest in differentiating their systems from their competitors', and modifying and extending Unix was an easy way to do that.

However in this case both Netscape and Netscape source licensees would have an interest in seeing their software be used as widely as possible (whether for monetary reward or ego boost or both), and the chances of success for any new product based on Netscape source (whether produced by Netscape or not) would depend on the degree to which those products could "plug in" to the existing installed base of such products.  It would be neither in Netscape's interest nor those of our source code licensees to introduce gratuitous incompatibilies.  (Again, GNU and Linux offer good examples regarding the ability to maintain a wide degree of software compatibility and interoperability even in a more loosely-organized development environment.)

It is possible that Netscape might lose some measure of control over the evolution of its products in terms of the exact APIs, content data formats, and protocols we use and support.  However we do not have complete control of these even today: We are constrained in terms of protocol and content standards support by organizations such as the IETF and the W3 Consortium, as well as by Microsoft's support of competing standards; we are also constrained in terms of API support by our installed base and our developer community.

In an environment of widespread source code distribution and licensing, we would have to accept some short-term loss of control, in the sense that the outside community of Netscape developers would be more able to influence the direction of our product evolution, even to the point of rejecting the Netscape way of doing particular things and converging around alternative ways of doing the same thing.  However we could and no doubt would still retain a significant measure of control through the use of the Netscape brand name and Netscape endorsement and promotion of particular standards.  And in the longer term we would gain greater control over the standards important to us because we would have more allies in the standards wars whose interests were at least partially aligned with ours; we would then no longer have to try and match Microsoft "body for body" in representing our interests in standards bodies.

"How could we coordinate outside developers creating fixes and add-ons?"

As shown by the Communicator development effort, it is a far from trivial problem to coordinate the efforts just of Netscape's own developers.  How could we possibly coordinate the efforts of potentially thousands of developers worldwide who might be creating bug fixes, customized versions, and add-on products all based on Netscape source code?

At first glance this would seem to be impossible.  However there is at least one example of a successful project involving distributed and relatively loosely-coordinated development of software products arguably at least as complex and functional as any of Netscape's products, namely the project to create the Linux operating system and the body of free software that runs on top of it.  The Linux project offers many lessons on how Netscape might potentially organize software development in the context of the proposed source code strategy.  These are discussed at greater length in the paper "The Cathedral and the Bazaar" by Eric Raymond, but some key ones can be summarized here as follows, together with implications for Netscape if we wished to pursue this strategy:

 It is important to note that there is no "free lunch" here: We could not simply release source code, put a few newsgroups up, and expect distributed development to magically self-organize; we would need to make a sustained effort involving various people's time and attention in order to get a distributed development effort to the point where it would produce results.  However I believe that the potential rewards could be worth the effort, and that we could not necessarily achieve comparable results by continuing current practices.

"Why would outside developers work on Netscape products 'for free'?"

I've spent a lot of space discussing how by distributing source code Netscape would be able to take advantage of the talents of non-Netscape software developers.  But why would those developers want to work with Netscape source code, especially those developers who are doing it noncommercially and thus in a sense are working "for free"?

First, developers are in large part attracted to working on software that holds the promise of helping them solve problems they themselves consider significant.  Netscape has created and should continue to create software that addresses important problems dealing with Internet- and intranet-based information, collaboration, and applications (in part because Netscape's own developers consider these to be significant areas), and it is a reasonably safe bet that other developers will find this software promising themselves and worthy of working with, especially if they have access to the underlying source code.

But once attracted to working with Netscape source code, what will keep developers interested in doing so?  The answers will vary depending on whether the developers are doing commercial or noncommercial development.  Commercial developers will obviously be interested in some way to profit financially from their work.  Working with Netscape source code they will have a variety of possible approaches open to them:

About the only thing commercial developers could not do with Netscape source code is found new software businesses "from scratch" totally unencumbered by source code licensing restrictions; in other words it would be difficult for them to become "the next Netscape" (or the next Oracle, or Microsoft, etc.), at least by creating the same sort of software as Netscape and Oracle and Microsoft are already known for.  (But this is already difficult for other reasons, and who today really thinks that the road to commercial success is to develop yet another operating system, or relational database, or web browser?)

For noncommercial developers the rewards would be different.  They would likely be motivated more by the ego reward of seeing their software used by other people and praised by other developers.  If starting with Netscape source allows them to build more interesting software, and if licensing terms are liberal enough to allow them to distribute that software worldwide with minimal restrictions (as proposed above), then it is very likely that they would be enthusiastic about working with our code.  It is even likely that they would agree to license provisions permitting Netscape to reuse their work for commercial purposes, as long as they could still distribute their own works, including source code, on a noncommercial basis.

"What about technical support for customers who modify source code?"

Providing technical support to Netscape customers is hard enough as it is, especially given the extra burden of providing at least minimal technical support to users who are not actually paying for technical support, whether these are home or academic users reporting problems on newsgroups, or enterprise users who are evaluating software and having trouble getting it working.  How could we possibly provide technical support in an environment where any user might be running modified Netscape software (either modified by themselves or acquired from other people)?

Traditionally companies providing source code to customers would "disavow all knowledge" if those customers had problems in using the code; that is, companies provided no formal technical support for products provided in source code form, and customers were considered to have "voided the warranty" if they were running customized versions of the products built from modified source code.  This is certainly one way Netscape could handle the problem of providing technical support for source code products: provide no support whatsoever.

However, if we intend to provide source code as a product instead of just as a special case, then we must provide (or cause to be provided) all the things customers expect to receive in a product, including technical support in particular.  How can we best do that?  Here are some possibilities:

As part of a wide-ranging program to distribute source code, Netscape might ultimately decide simply to out-source technical support altogether for certain products, for example earlier releases of current products or products no longer deemed key to Netscape's business.

Action plan

Suppose other people in Netscape, including Netscape management, agree that we should at least consider a development, sales, and distribution strategy for source code like that proposed in this paper; what should we do next?  Here is one possible three-phase approach to implementing such a strategy:
  1. Take advantage of the experience we've already had with source code licensing and distribution, including the public distribution of the SSLRef and IFC source code, as well as any other private source code licensing deals that we have concluded (or have considered) with other companies (e.g., SGI).  Did licensing source code provide any concrete benefits in any of these cases?  If so, what were they?  If not, why not?  What extra work (if any) was required in distributing source code?  What special licensing terms and conditions were used?  For those deals where Netscape was paid for licensing source code, what types of pricing schemes were used (e.g., one-time, continuing royalties, per-user)?  Was source code pricing consistent across deals?  The previous examples of Netscape distributing source code were to a large degree ad hoc and sui generis, and not done as a part of any comprehensive strategy; nevertheless the answers to these questions may be useful in determining how we might proceed with a more wide-ranging strategy for source code distribution.
  2. As a pilot for the strategy, consider releasing full or partial source as part of the upcoming Gemini developer releases, either DR1 this fall or DR2 next year.  This would be a controlled experiment to investigate possible payoffs of the strategy as well as reveal any extra work that would be need to be done to implement it more extensively.
  3. Do long term planning for a possible full implementation of the source code licensing and distribution strategy with the Xena client release, followed by implementation of the strategy for future SuiteSpot servers.

Appendix

Acknowledgments

This paper was inspired by discussions on various Netscape internal product development newsgroups about the implications of releasing future Netscape software products written in Java, JavaScript, and HTML; of particular interest to me were an article by Jamie Zawinski in the Xena and Magellan newsgroups, and an unrelated article by Eric Krock in the JavaScript newsgroup.

Special thanks go to two people who reviewed early drafts of this paper: John Menkart, who helped with formulating suitable licensing and pricing models, and Jamie Zawinski, who provided useful information on software development according to the GNU and Linux models, including a pointer to Eric Raymond's paper.

Revision history

0.7
Revised answer to the objection concerning exposure of proprietary material in source code.
0.6
Made minor revisions and additions.
0.5
First complete draft.  Rewrote introduction.  Wrote rest of responses to objections.  Made minor revisions throughout.
0.4
Wrote action plan and more responses to objections.
0.3
Wrote responses to more objections.  Refined the licensing and pricing section.  Added a disclaimer.
0.2
Tightened up the introductory material.  Added more material on suggested licensing and pricing.  Wrote responses to the first few objections.
0.1
First draft.  Fairly complete main argument, skeletal objections/responses and proposed action plan.
Revised 11 November 1997
Frank Hecker - hecker@netscape.com