Slashdot Mirror
New ESR paper: The Magic Cauldron
Thanks to webmaven for sending us 'The Magic Cauldron', the latest piece by ESR. The paper "anaylzes the evolving economic substrate of the open-source phenomenon." As always, very timely and interesting reading, considering the IPO announcements and more news of investment from folks "oustide" of the Linux world.
Anonymous Coward wrote:
On the other hand, there are examples of people buying "old unsupported software" Witness some people going back to older versions of Word Perfect, or buying classic video game compilations.
Older versions of WordPerfect are still supported. You can even get things like the HP LaserJet 5si printer drivers for WordPerfect 5.1. In fact a writer friend of mine has recently contacted Corel with a question about WP5.1+, and not only got a knowlegable response (consider that Corel had no part in developing WP until version 7), but found that program development is still very much active, particularly maintaining internationalization and driver support.
As his article pointed out, video games are a special market all their own, with different rules.
----
Open mind, insert foot.
Brooks' Law is "Adding programmers to a late software project makes it later." I strongly dispute Eric's claim that open source overcomes Brooks' Law. While open source may have advantages, super-speed in initial development is not one of them. It may be quick to *fix* vital bugs, but that's another matter. How fast is AbiWord being developed? Mozilla? (And how does the latter compare to the "Internet time" upgrades we used to have with browser versions?)
P.S. It was a pleasure working with Dr. Brooks as a grad student.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
This is interesting, because it makes me think about Apple. Remember when they orphaned the IIe? What if, instead, they continued support on a pay-per model for the outdated product?
I plan to write followups to both "The Cathedral and the Bazaar" and "The Magic Cauldron". I have a few ideas in mind for titles. Hopefully, these will be in the same spirit as the originals:
1. Knights of the Boardroom Table
2. Open Sorcery
3. A Code Jester in King Richard's Court
4. Slaying the Proprietary Dragon
5. Use the GPL or I'll Get Medieval on Your Arse
(All due respect to ESR, of course. I'm just having fun here.)
Save the whales. Feed the hungry. Free the mallocs.
I want to see some statistics that prove that people who agree with Stallman are only a minority of members of the open source community. Without that, this looks like just another attempt by our friend Eric to minimize the very real concerns many of us have about the real freedom of our software. Yeah, all that other stuff is nice, too, but three out of four (quality, reliability, and choice) are quite possible with proprietary software too. All you need are developers who care about the product and the customers rather than just the stock options.
You've got a vlarge company with about 15 significant competitors. You have developed an in-house piece of software "Y" to run all aspects of a new (and highly competitve) line of business. The software has extreme use value, but no sale value.
What I don't see Eric's model capturing is the fact that you would want to keep "Y" closed-source to prevent competitors from gaining benefit from the technology, code fragments, business models, etc of "Y". You're not afraid of your competitor making and selling "Z" from it, but from using it to gain insight into your business or to enhance their business in a way that causes revenue loss not directly related to software.
Does this connect with anyone?
My biggest problem with the way esr writes is that he has an unfortunate tendency to joust with straw men. His deconstruction of "The Tragedy of the Commons" is a rather sophmoric set of straw men. It always surprises me to see such fuzzy thinking from people who otherwise pride themselves on rational thought.
When in danger or in doubt, run in circles scream and shout.
Eric Raymond makes a very good point in noting that the value in software is more in maintenance and support than the product itself. In light of this, there is perhaps an additional business model that supports this notion without requiring source code to be freely available.
Consider a software company that leases software. Business's pay to use the software on a yearly basis (for example). This gives the software company a steady stream of revenue based upon the number of people using their software. In return, the users get support, timely maintenance releases and future features.
To make this example more concrete, consider the accounting industry. They certainly can benefit from software that deals with the everchanging tax codes. Now, most accounting firms are small and it doesn't really make sense for them to collaborate on a software project when they have no programming expertise. They're accountants, not hackers. Also, due to their size, it's not feasible for them to hire programmers for this task.
Here, a software company fills a definite need. As experts in their domain, you can expect the software company to keep abreast of the frequent regulation changes in Washingtion, DC, and update their software accordingly. Accountants need to do accounting, not hacking away at some monstrous piece of software on a regular basis.
So, the accountants, in essence, pay to use the software as service (one that's updated regularly), not as a product. Here, the software company has no reason to release their code. What might happen? A competing software company might snatch it out from under them and take their revenue away. It is after all service based, but someone had to make the initial investment to get the ball rolling. The company benefits from closed source, and at the same time has enough revenue to properly maintain and support their software.
This, I think, is a viable alternative to the business models that Eric suggests. Unfortunately, not everybody who uses software is a webmaster capable of writing his own, nor is it the agenda of most companies to delve in writing software. They'd rather being doing what they're good at, and leaving the software to experts, namely a software company who steps in to fill the need.
Note, this is not the typical consumer software market, but these applications probably account for more software and certainly more revenue (SAP?).
So, in conclusion, there's money to be made from software as a service, and let's leave the coding to people who specialize in it, rather than laymen who just want to use the software.
>Freshmeat needs MODERATION.
Or at the very least, reviews. This is something I've been thinking about and really missed for open source stuff. Can't code but want to contribute? Think about setting up a reviews site and reviewing what does exist.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
You said it yourself: "... and benifits from improvements made by the community."
You now have a better accounting package than you started with, with no extra investment on your part. You then just need to answer the question of whether the advantages you gain from the better accounting package outweigh any competitive advantage you might have from being the only one with a not-as-good accounting package.
Of course, in an increasingly free-source world, odds are that sooner or later someone will create a free source accounting package, and then your competitive advantage will dissolve anyway...
I'd love someone to explain this better. How are developers supposed to make money in this brave new OS world?
The only avenue I see in ESR's document is to be picked up by some benevolent Accessorizor who thinks my efforts will help them sell more accessories - the 'Open R&D' idea.
That sucks. Let me explain my situation:
I am a partner in a small software development firm. We have 5 staff (including the partners), and write applications for a specialised sector of the market. The major application we develop is a high-ticket, low-volume product.
We may have some small competitive advantages over others in the same arena, but that's not important. Niche application software does not win on technical merits, however much I would like it to. It wins on how good a job the sales people do at convincing the customer that our product is better for their purpose than someone elses.
Right now the product is closed source. It is never likely to be something everybody has on their desktop, in fact we think the product will have a limited lifespan, say 5 years. As technology advances, the functionality that our particular software offers will not be as necessary as it is today.
I can live with that, and I think that closed source is the best way for this product to remain. It's sort of like the Doom example, before they open-sourced it. Plenty of reasons for ID to open-source Doom, AFTER they had made back the R&D cost, plus a little profit. But should they have open-sourced Doom from the beginning? Not in my opinion.
Judging by some of the comments here, a few people would disagree with that statement. I don't think that's reasonable. I'm not in this for the money (well, maybe a little). I love to program. I'd like to have the freedom to program whatever I want, help write open source software, change the world, etc. and than means I need a way to support myself financially. I'd write open-source software all day long, if someone would only pay my bills.
If we keep our product closed, I can probably make enough money from it to finance my personal programming projects. If we open the source, I don't see how I can do that. Can anyone point out what I'm missing?
I'm an Anonymous Coward because I fear the flame.
I agree. It seemed more an act of reciprocal generosity on Carmack's part. Basically a sort of "hey kids, thanks for helping us sell DOOM with all those pwads and stuff, here, now you can play with all of it".
I doubt releasing the DOOM source brought id much additional revenue.
BUT...
I do think id's games are a very strong example of the power of the open source development model, but not one that is relevant to commercial enterprises, since id kept a lot of "secret bits" to themselves, and mods to Quake or DOOM had to be non-commercial. But by allowing mods to be made, and releasing the code and tools to help people make them, id allowed the formation of an entire community of developers who increased the value of the game well beyond what they paid for it. Of course it also benefitted id, since it made the games much more popular.
> A key fact that the distinction between use and sale value allows us
> to notice is that only sale value is threatened by the shift from
> closed to open source; use value is not. Let's say you hire someone to
> write to order (say) a specialized accounting package for your
> business. That problem won't be solved any better if the sources are
> closed rather than open; the only rational reason you might want them
> to be closed is if you want to sell the package to other people.
This is not true. ESR misses a very important and commonly stated
reason: a company may believe that exclusive access to a piece of
proprietary software provides the company with a competitive
advantage. For example, a microprocessor-design company might embed
considerable experience and research in a computer program to improve
the quality of CPU designs. They might quite rationally believe that
if they gave that software away, their competitors would use it to
improve their own processors and take business away. H&R Block may
quite rationally believe that their tax software is enough better than
the competition that it garners them customers or increases the
efficiency of their preparers. BMW may quite rationally believe that
their engine-design software allows them to build better engines for
less money and sell more cars.
In many cases, this is delusional, but in other cases it is
undoubtedly quite justified.
It is odd that ESR missed this point, because I think it is the
fundamental reason behind the difference between the GPL and BSD-style
licenses. RMS realized that there is a large incentive for companies
to "take software proprietary", and went to great lengths to prevent
it in the GPL. If "taking software proprietary" were wholly
irrational, there would be little reason for going out of one's way to
prevent it.
ESR actually alludes to this, tangentially, later in the article:
> (One objection sometimes raised to open-sourcing hardware drivers is
> that it may reveal important things about how your hardware operates
> that competitors could copy, thus gaining an unfair competitive
> advantage. Back in the days of three- to five-year product cycles this
> was a valid argument. Today, the time your competitors' engineers
> would need to spend copying and understanding the copy is a
> substantial portion of the product cycle, time they are not spending
> innovating or differentiating their own product. Plagiarism is a trap
> you want your competitors to fall into.)
However, his rejection is rather specific to hardware drivers, and
rather flippant as well. The real reason it is rational to
open-source a hardware driver is that the expansion of the potential
market to Linux and BSD users more than makes up for the loss of
trade secrets.
People please don't try to fit a square peg into a round hole. ESR is not advocating OSS for EVERYTHING. There is a time for OSS and there is a time for CSS. It is a strategic business decision that can result in some amazing synergies. If it is just you and one other competitor, you are correct, OSS'ing your software probably won't help you unless your competitor agrees to develop it further as well. A larger audience attracts more developers which attracts more innovation free of charge. The business decision in that case is to decide how much that free innovation is worth to you. Original development costs are sunk, you can't get them back. OSS will help you get some free innovation. Consider it interest on your original development money...
OSS is a major conceptual shift, one that many can't immediately grasp. Don't give up, you will benefit from understanding it.
-Chuck
*Condense fact from the vapor of nuance*
To me, anyways, after reading this latest piece. The notion of being reimbursed for your efforts (as Stallman and others insinuate) through software 'support' simply does not apply, especially as regards games. People bought Doom because they wanted to upgrade from the shareware 'teaser', not because they wanted software support--the people who make money in this case are those who wrote the help books; if id simply GPL'ed Doom in the first place, they'd have been out of business long ago. 12 year old kids aren't going to ask for help playing games, they will ask from their friends. The reason they released Doom was simply because it was obsolete at that point.
Raymond's argument instead infers that an evolutionary ecosystem would have built around the Doom code, a la Linux, to somehow make it better. This simply has not been the case--old code is dead code. Why in general would any gaming company want to GPL their source code?; games have a very short lifespan, and their success is based on the fact that they have something others cannot copy.
In the Linux world, you have (too) many versions of Tetris and Minesweeper, mostly as coding exercises, but nothing really unique or compelling--which I suspect is Open Source/GPL's real weakness: lack of originality. Linux can only follow Windows precedents; there is no economic incentive to carry out the research to do something truly innovative (emacs still thinks there's no mouse). The tech carrot pulling the industry these days is $$$, *not* 'making software that doesn't suck'; rather the inverse seems to be true, i.e. making sucky software guarantees $$$.
Scenario B: what if Bill Gates got hit on the head tomorrow with one of his many inhouse videocams, and decided to GPL Windows and Office? (Raymond should have brought up this at his talk); what possible advantages could there be? Netscape did it in hopes of making a new open standard and breaking the Microsoft stranglehold; as far as I can tell with Mozilla, they haven't succeeded. As for Windows, they own the standard OS as well as the desktop suite. What advantages could there possibly be for MS? So that MS can make money printing books instead? So that Corel could take and rebrand it Corel Office? So that IBM could finally have Windows back from Bill?
Someone please explain this 'logic' to me; though a lot of this appears as a troll, I am perfectly serious--I'd like a real, not some second rate sociological mythmaking about tribal 'gifts' and so forth.
1) You are assuming that the proprietary-to-company stuff is open sourced, such as, e.g., the license key generator. This is a ridiculous assumption. Nothing requires you to distribute your software even if it is covered by the GPL. Not to mention that any competent project done in today's world is going to have a modular plug-in architecture, meaning that you don't even have to link your proprietary business practices into the code base as a whole (i.e., they don't have to be covered by the GPL just because the rest of the project is!).
2) Let's face it, most business process software has been hashed and rehashed until it's so old-hat that there's no competitive value in keeping it proprietary. How many #@%@ accounting systems are out there in the market anyhow? Why should I think that my own new accounting and inventory management software gives anybody any competitive advantage? There are industry and government standards that force any accounting or inventory software to be pretty much the same. By Open Sourcing it, I accomplish two things:
a) I allow others outside of my company to take on some of the development costs. As my boss once told me, "nobody is ever going to buy us because we have a nifty internal accounting system, they're going to buy us because we have a nifty product." This, for example, is why ISP's use Apache. The bigger ISP's have the internal talent to write an HTTP server -- heck, I have enough talent to do that, HTTP is a dirt-simple protocol (though the 1.1 spec, thanks to Microsoft's help, is considerably nastier) -- but it makes more sense for them to all use Apache and individually contribute modules and improvements that fit their own needs.
b) I get a larger debugging pool. In fact, I might release the GPL'ed version to the net first, before upgrading to it in-house, just to let others be my guinea pigs first. After all, if it turns out that my Accounts Recievable program is eating accounts, I'd rather that someone else discover it first!
One more thing: Once a project reaches a stage where any improvements will incorporate company-proprietary business methods rather than industry-standard or government-legislated business methods, there's nothing forcing you to continue distributing it. You've gotten help in building the basic framework, others can take that basic framework and do what they like with it, and you can happily use your own proprietary version in-house without ever releasing it to the general public. The GPL doesn't stop you from making your own proprietary version. It just says that IF you distribute it outside of your company, you have to make the source code available too and must allow the person who got it to distribute it too.
-E
Send mail here if you want to reach me.
For a paper that reads like a simplified version of the Other Eric's, you might want to wander by my home page to read something I did last year and sent to the Other Eric back in January for comment. (Please note that the Other Eric had parts of 'Cauldron' already up on his web site back then, so we sort of cross-pollinated, I think).
Send mail here if you want to reach me.
Posted by FascDot Killed My Previous Use:
Not only are quality, reliability and choice possible with proprietary software, but each of those has a "good enough" variant that is very dangerous. And, unfortunate as it may be, many in the "Open Source" community are accepting "good enough" Free Software, too.
---
Put Hemos through English 101!
First, let me congratulate esr on yet another thought-provoking essay. I'd like to bring up just one point, however, that was brushed over in this essay, specifically section 4 - "Information wants to be free".
Eric, you've setup the basic of an economic model to base open source on. This lays to rest many questions of the economics behind the free software movement. But you skipped over a central point - one that's debated and brought up daily across the geek community - the idea that information should be free.
Two cases: MP3s and "warez". Despite wide-spread media campaigning and propaganda, not many people consider this to be "wrong". The simplest arguement - is that it's free - and if it's free, why should I go elsewhere (possibly with more hassle) to have the priveledge of paying for it? Especially considering the cost-benefit of getting caught is so low.
This is an issue that desperately needs to be analyzed and thought out. Programmers modus operanti is "copy rip copy" from other programmers. It makes economic sense - why reinvent the wheel? MP3s mean (nearly) zero cost to aquire something you want (music), and this broadly applies to almost anything that can be distributed digitally. Today that means about everything.
What's stopping people from simply pushing the download button and getting something for "free"?
--
Not true. When I was doing consulting work, we regularly could underbid proprietary solutions by using Linux, giving us a significant competitive advantage while actually maintaining a higher margin than our competitors. We used a 4GL under Linux, BTW, and served as the IT department for school districts too small/poor to have their own. We could whip out some software pretty quickly too -- for example, when the state of Louisiana changed reporting requirements for school discipline, it took me two weeks to write an entirely new discipline system to replace the old one that had collapsed under its own weight. (Well, it hadn't collapsed, but it had reached the limits of what could be done to it due to structural design limits built into it, sort of like trying to turn MS-DOS into a 32-bit OS, eh?).
So tell me: underbid the competitition, make more profit. If that's not competitive advantage, what is?!
-E
Send mail here if you want to reach me.
Isn't ESR just totally off base on the whole Doom analogy?
If I remember correctly Doom source was only released after Quake was out (or at the very least after Quake was well into production). And I'm pretty sure there's very little shared code between Quake and Doom, considering the engines are drastically different, as is the networking.
ESR seems to imply that id switched to an open source model, while really, I think Carmack just decided to be cool and release Doom source because he thought it would be a nice way for people interested in 3D engines to cut their teeth. Releasing Doom source was no threat whatsoever on Quake, as it was significantly more primitive. To this day, Quake and Quake 2 (and Quake 3) are still closed source, because Carmack is still pushing the envelope and doing things better than anybody else.
id released source because they wanted to give people something to learn from, not because they wanted to increase their quality. To this day they depend on closed source software and traditional testing to make their (high quality) games.
So where does ESR get off making them an example? Didn't he do his homework, or am I just mistaken?
-Nic
AtariDatacenter asks:
You've got a vlarge company with about 15 significant competitors. You have developed an in-house piece of software "Y" to run all aspects of a new (and highly competitve) line of business. The software has extreme use value, but no sale value.
What I don't see Eric's model capturing is the fact that you would want to keep "Y" closed-source to prevent competitors from gaining benefit from the technology, code fragments, business models, etc of "Y". You're not afraid of your competitor making and selling "Z" from it, but from using it to gain insight into your business or to enhance their business in a way that causes revenue loss not directly related to software.
You seem to be talking about trade secrets, specifically, where something about the software can reveal valuable secrets about how your company operates. In at least 95% of such cases, forget about Closed vs. Open, you shouldn't be distributing your software at all. It should be in-house only, with perhaps distribution with a few trusted consultants and partners under an NDA. Don't think that the competition can't reverse engineer the trade secrets out of your closed source distribution, it would just cost a little more for them to do it.
For those few companies who have to distribute software that they want to keep the mechanics secret (eg. hardware drivers), first they should review their secrecy motives. If there is something real there, it is both inexpensive and more effective to keep the secret parts in hardware (eg. a Flash ROM chip on your card), and publish the rest.
----
Open mind, insert foot.
There is a distinction between closed-source development being a bad or inferior plan and it being morally or ethically wrong. While RMS believes that closed software is ethically wrong (because it does not permit users to share), ESR apparently believes that closed source is not wrong, but simply limiting.
In a sense, this means that ESR comes off as having more confidence in the success of free software on its own merits, whereas RMS feels the need to actively fight and incite people against closed software. RMS seems to think that free software is endangered or placed at risk by the continuing popularity of closed software.
I suspect that RMS gets this attitude from his own history in the MIT AI lab, where free software was forced out in favor of closed software by managerial decisions and local culture changes. However, I find it to be inappropriately applied to Linux-based and other modern free systems. While the AI Lab was a single site, Linux is a worldwide distributed phenomenon; it cannot be shut down in the way that the systems RMS mourns were.
I couldn't help but notice that ESR managed to write a 20 page essay on the future of software without mentioning a certain company from Redmond or a certain individual worth ~$90,000,000,000.00 even once :-)
Moral Calculations, by Laxlo Mero, is an interesting book that discusses a lot of general game theory, and in particular, a couple modes of cooperation. The classical model for thinking about cooperation (see The Evolution of Cooperation, by Robert Axelrod) is the prisoner's dilemma. It's a positive-sum game only if we both cooperate, but as individuals, we are always tempted to defect. A number of people have pondered what incentives could be used to encourage cooperation. Axelrod's contribution was the observation that repeating the game many times with the same opponent introduces new long-term pro-cooperation incentives.
Mero's book looked at the Golden Rule and Kant's categorical imperative. For purposes of game theory, the Golden Rule says: optimize the other guy's payoff, ignore your own. This flips the payoffs and always favors cooperation. The categorical imperative says to do whatever you would want everybody to do, if you had such legislative power. In other words, ignore the off-diagonal payoffs; again this favors cooperation.
Another mode of cooperation might be a communal rule: consider only the sums of the payoffs for each situation, never those of any individual. Adherence to this ethic is good for the community as a whole, and probably the individual practitioner in the long term. In the short term, the practitioner gets to look heroic, which involves additional payoffs.
The Tragedy of the Commons is a multi-player prisoner's dilemma. If the payoffs are increased by some constant, you end up with Raymond's Comedy of the Commons, where a cooperative few can support a large number of non-cooperators. Add to that Axelrod's long-term incentives due to recognition of others and reciprocal behavior, and that's more or less the OSS world.
One last book recommendation, an excellent book on economics, Hidden Order: The Economics of Everyday Life, by David D. Friedman.
WWJD for a Klondike Bar?