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:
- Intensification
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.
- Obsolesces
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.
- Retrieves
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:
Encourage wider use
Encourage others to contribute improvements and bug fixes
Reduce the cost of providing a population of people that can use and support the software
Represent "free advertising" of their software so that organizations wishing to use the software in proprietary ways must pay them something extra for this
A few examples of this include:
The Zope web application environment.
Eriksson's Erlang language
Enhydra, a Java-based application server
Recent indications are that there may be some degree of "bait-and-switch" involved with this one; the "enterprise" version of Enhydra is apparently no longer being released under "open source" licensing arrangements.
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:
Increased exposure of the public to their software. If the software is well-regarded, this reflects well on the original producer.
Reduced software maintenance costs.
If someone wants to do an port of Erlang to some obscure platform, this doesn't require special licensing arrangements and trade secret arrangements. Enhancements and problem remediation can be distributed, which encourages the growth of a larger, livelier group of "people that understand Erlang."
Reduced training costs to the producer
If Erlang is more widely usable, this encourages academic use, as it means they're not "merely supporting Eriksson's proprietary tool," as well as use by other third parties. This may result in the growth of people outside Eriksson that understand and use it. Which means that Eriksson has the possibility of hiring people that might already know the language, rather than knowing that they will have to train them up on the job.
Reduced risks to customers.
When Erlang was a proprietary Eriksson tool, this meant that users of Erlang-based software were dependent on the continuing support of Erlang by Eriksson. With the "open sourcing" of Erlang, the risk is reduced somewhat.
This may be of greater importance for smaller companies when they build application frameworks. Some years ago, I worked for a small consulting firm that created their own "application framework" called the Nidak Application Generator. The use of NAG required that clients forever after trust that our firm would be around to support them. When Nidak was taken over by a bigger company, this very much became an issue to customers. Software developed using NAG ultimately had to be retired and replaced, not just due to technical considerations, or changes in system requirements, but for the "political" reason that the new company was not critically interested in continuing to support NAG.
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: |
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.
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:
R/3 is a "source available" system.
While it is proprietary software, those that work with it have access to system source code. Many of the benefits that accrue to people using free software, notably the ability to understand and make changes to the underlying system, apply to R/3.
Of the cost of a typical R/3 implementation, only about 25% of the cost comes from licensing of proprietary software. 10% comes from hardware. And the remaining 65% is for services.
SAP AG, producers of R/3 , have used this economic model to encourage the widespread use of their software. Most other ERP vendors appear to be more "greedy," trying to deploy as many of their own consultants as possible so as to maximize their revenues from projects to implement their software.
In contrast, while SAP does deploy a significant population of consultants that are highly knowledgeable about their software, they have actively enlisted the participation of third party service providers, and do not discourage at all this sort of third party participation. Thus, consulting firms see R/3 projects as being lucrative opportunities, and not merely a good opportunity to do some work and watch SAP AG walk away with the money. And therefore they all put diligent effort into selling R/3 to would-be clients.
The relevance of this to free software is that the bulk of the costs and revenues associated with R/3 are associated with things other than licensing. This should be encouraging to people in the free software community.
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.