Christopher B. Browne's Home Page

5. Organizational Changes

In the presence of free software, the assumption that revenue comes from control over licenses is not true, and software is no longer an asset for which the control thereof is highly valuable.

This changes the sorts of organizational structures that can grow up around computer software.

Note that this is not a particularly novel idea; computing has changed quite a lot over the last 40 years, and there are doubtless some old ideas that may be "retrieved," in the terminology of Marshall McLuhan. His "Laws of Media" ask four questions that he considered critical about any given artefact:


What does it enhance?

Free software enhances the ability of software to be widely supported and deployed. It likely enhances the ability of service-oriented organizations to thrive.


What does it make obsolete?

Free software tends to make obsolete proprietary software as well as organizations dependent on the proprietary nature of software.

A problem with it is that it obsolesces some methods presently used to fund the production of large software projects, in particular by denying the ability to charge for licenses to recover production costs.


What does it bring back that was previously obsolete?

Free software hopefully retrieves some of the sense of "community" of early computing where developments were shared.

Reverses Into

What does it produce or become when pressed to an extreme?

Answers to this question are less clear...

I suggest that these are good questions to ask about free software, and in particular about its effects on organizations.

The following material provides some "case studies" on how free software might be made to work in some specific sectors of computer software production.

5.1. Freeing Software that is a Secondary Product

Several organizations have chosen to release software that they have produced under free licenses in order to:

A few examples of this include:

For the most part, the associated companies sell things like consulting or systems integration services; by releasing software in a free form, they receive the following benefits:

If Eriksson considered Erlang to be a major product for which they expected to gain considerable revenues, all these arguments might be for naught. But since their "core competency" is building telecommunications products, and that is where they make sales characterized in hundreds of millions of dollars, these causes to "free" the code proved sufficiently compelling for them to do free releases.


This material was written in around 2000 or 2001, at which point Erlang was mostly a curiosity. A decade later, there are a significant number of Erlang-based applications, notably:

  • RabbitMQ, an AMQP server

  • Parts of the SCM hosting service, GitHub

  • A Jabber implementation called ejabberd

  • The CouchDB document database

5.2. Deploying Video Games as Free Software

A discussion came up in early 1999 on gnu.misc.discuss where a skeptical individual who builds video games for a living wondered how free software could conceivably be supportive of producing video games.

There were some assorted clueless comments here and there suggesting either that it was impossible, or that "video games are a worthless application so that it doesn't matter," or that "as soon as someone looks at it, they'll come up with a GPLed game engine, and the video game makers will be out of jobs." Which assortedly betrays lack of imagination, lack of willingness to consider other peoples' desires, and lack of understanding of what all goes into making a game.

The following was my response to the matter.


(to the question) "How can we make GNU and Open Source work for the games (entertainment) industry?"

I agree with the other poster. You can't entirely. What you want to do, it give away the reusable, you don't want to maintain it, you want others to maintain it parts (the engine), and sell the hard to create (content) parts. The engine can survive for decades and be expanded and the functionality enhanced. All of this work, you can benefit from others doing and contributing to. Also, if someone else has it, they still don't have your game, they still have to create the content. Also, if lots of people use your engine, hiring replacement programmers is much easier, further reducing your costs.

-- Mike Stump 

I don't agree that "You can't entirely."

To be sure, the gaming industry does not provide the means at this time of supporting games in a GPL-like form. That does not mean that it is not possible.

There are absolutely some interesting possibilities in terms of building "game engines;" that is surely something that could be "GPLable," and be useful as an "embedded component" of a game.

However, in a good game, the valuable elements will be things like artwork, "element sequencing," and the interactions between game components. In the old Infocom "text adventure" games, the engine wasn't what game players were buying; it was the puzzles and the "text." Today, you need to add graphical elements and the ways they are made to interact. That's where the value to the game players is, and where much of the cost of game development comes from.

At present, proprietary software has its development costs "sponsored," typically by the company that is going to sell it, on the basis that they will be able to recover the development costs based on selling "licenses" to the software. This is true whether we're talking about IBM "sponsoring" development of Lotus Notes, SAP AG paying for development of R/3, or Sony Entertainment paying for the development of PlayStation video games.

With the way the GPL works, once a system is released, it becomes difficult to directly capture revenues to pay for the costs of development. It's easy enough to sell such things as "service," or "distribution costs," or printed documentation, but those are not something where the producer of software can be an exclusive source.

Some people spend extra money on Red Hat's Linux "distribution" with the expectation that some of this money will be used to pay for further development, which I believe points to the way that development needs to be paid for in a "free software" system, which is essentially via paying to "commission" new software.

Since the GPL (and, similarly, other licenses such as LGPL , BSDL , XFree86 License, ...) undercuts the ability to charge a hefty price to license software once it is released, this means that in order to produce things that cost a lot to produce, and don't have natural ways of encouraging extensive secondary spending (like service/distribution), it is necessary for the would-be users to themselves pay to "commission" the works.

In the case of a video game, the present model is that Sony may pay $2M up front to pay a team of developers for a year, and then sells games for $60 a pop, (let's say) selling a million copies, out of which they use $2M to recover the initial investment. Note that the users thereby have spent $60M in order to cover a $2M "cost of production." (This might be true for a game that sells really well; other games may not sell enough copies to cover the cost; since the market remains viable, it must balance out favorably for the producers...)

In order for this to "work" in a GPLed environment, the users will have to band together $2M to pay for the game. If there are to be 20 games produced per year, a population of 1 million game players have to prepay out 20 times $2M, or $40M, which represents $40 apiece.

Building up a system to support that is a bit of a leap. But the economics of it is clear enough.

-- Christopher Browne  

Some people seemed a little astounded by this news posting, and immediately thought it a "cool idea" to start working to found a "Video Game Club" to fund things this way. It seems to have gone little further, which supports my final comment that "Building up a system to support that is a bit of a leap."


People are buying the best game and this is a control parameter. That makes it hard for people to pay to commission new software, because they cannot understand, what motives the people to make the best game, when they have the money already. And who is liable if the game is not that good?

-- Bernhard Reiter  

The English may be a bit painful, but the point is insightful, and suggests the following question: " How does such a project make sure it finds people to pay that are capable of building a good game, and ethical to produce what they promise to? "

This is a difficult issue. It is, of course, a reasonable idea to entrust resources to people that have acted competently and faithfully in the past. It is, however, a problem to do this the first time, when there is no track record to look back at.

5.3. The Scorched Earth Strategy: One Excuse to Free Software

Russia has been noted for its implementation, in the military forum, of what is termed as a "Scorched Earth" strategy. This refers to the situation where one is in a defensive position against an opponent who holds a seemingly superior position, and, as a defensive measure, retreats from the opponent whilst "scorching" the ground so as to deny the opponent benefit from their offensive advance.

The hope is that the opponent's advances are made costly, and that the opponent is encouraged to overextend their logistical arrangements, ultimately weakening their forces so that they may be expelled later.

This strategy proved effective against both Napoleon and Hitler, where French and German expeditionary forces advanced well into Russia, but later found their forces essentially destroyed by the cold Russian winters.

More recently, Netscape Communications Corporation took a similar tack with the "open source" release of Mozilla . They had a product that was not generating significant sales revenues in the wake of Microsoft's Internet Explorer being widely available gratis. Since it seemed unlikely that they would receive revenues from the sale of Mozilla, Netscape chose to release the source code as free software. Note that they have not done anything similar with respect to the server-side software.

Other commercial enterprises may be able to be convinced to release the source code to software for which development efforts represent sunk costs, and there seems to be little chance of them receiving significant revenues from selling software licenses.

This is not a route to a "Brave GNU World" where all software is free; if enterprises can be convinced to release some software as free software, this still provides benefit to all, and provides them with opportunity to see what rewards come from doing such releases.

5.4. ERP Software: Not Quite A Case Study

The ERP (Enterprise Resource Planning) market has become dominated by R/3 , and even though it is proprietary software that is definitely not free, it still has some interesting things to tell us.

Consider the following factors:

5.4.1. A GNU ERP View

Supposing there were no licensing fees for a modular R/3 -like system licensed under a license like the GPL, this would provide consulting organizations with every bit as much benefit (if not more); they could expect to receive an even higher proportion of monies spent implementing GNU ERP.

It would make sense for companies to commission (as described earlier) the creation and improvement of modules to provide new and improved functionality; since they wouldn't have hefty license fees to pay, there would be considerable money left to help pay for programmers to add functionality.

A "cool" idea would be if SAP AG were to make R/3 into free software. This seems extremely unlikely, for the following reasons:

  • SAP is receiving goodly amounts of licensing fee revenues, and would be understandably reluctant to give up that revenue.

    They do receive revenue from other sorts of sources, including the provision of services. But there is no clear way of turning their situation into one where some form of "benefactor" is responsible for commissioning new development.

    This is quite unlike the situation where Netscape Communications Corporation released Mozilla in an "open source" form; SAP has an entirely lucrative business selling licenses for R/3 , whereas Netscape didn't due to the "gratis" availability of other web browsers.

    There is a "flip side" to this; SAP acquired licensing rights to the former Adabas-D SQL database, and released it under the GPL family of licenses as SAPDB.

    SAP isn't in the business of selling database software; it is a component that they use, so it is not overly remarkable for them to make SAPDB freely available.

    Eventually, they sold rights on to MySQL AB, so the situation did not remain stable; this was not really the business they were in, so that is no surprise.

  • R/3 depends on a variety of proprietary software from other vendors, including proprietary relational databases, GUI toolkits, and the like.

    As a result, making R/3 usefully free would require a substantial effort to replace a whole lot of its components. The Mozilla project had similar third-party issues, which is part of the reason why, two years after the source code release, there was not yet a fully usable release.

Contact me at