Slashdot Log In
Commercial Open-Source Software
Posted by
CmdrTaco
on Sun Apr 04, 1999 10:43 AM
from the stuff-to-read dept.
from the stuff-to-read dept.
Paul Johnson writes "I've
written an essay on where I think the OSS movement should go. I think it needs to commercialise itself, but on its own terms not on the terms of the conventional closed-source software industry.
This essay looks at the pros and cons of both the closed and open source worlds, and then outlines a synthesis of both which I hope will have the advantages of both.
"
This discussion has been archived.
No new comments can be posted.
Commercial Open-Source Software
|
Log In/Create an Account
| Top
| 187 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
A good essay however... (Score:5)
As a result of these experiences I've come to the conclusion that I was thinking about it all wrong. The current way of doing things has already evolved into a highly efficient means of production. Things that need to be done get done. Things that aren't important fall by the wayside. (As an aside, this is why Gates' comment about no roadmap is totally irrelevant. By not having a roadmap, we are ultimately free to do whatever needs to be done, and we aren't overcommitting ourselves to a project that nobody wants). There's no need to change the way people write software, things will happen on their own, after all that's the beauty of a market economy, is it not?
Lots of people have said something in these forums. The real economy in OSS development is the economy of time and talent. The projects that are the most interesting, or are needed the most (etc.) are the ones who will receive the most developer time. There is alot more to this, and I'm sure it'll make a good masters thesis for somebody, but to really understand open source software you have to shed all your preconceptions and intuitions about commercial software. The two are fundamentally at odds with eachother.
Commercial development corps generally see software as a product, something which can be sold for money. Open source developers see software as a tool. A tool which they can use in their lives. Of course, I'm just speaking in vague generalities here, but in general this is the case. (Case in point: how many developers of OSS applications are writing the package for money? none that I know of.)
A Thought Experiment (Score:3)
Now RedHat currently has 450 packages, and I doubt this scheme would be viable if the average price per package dropped much below $1. So RedHat has two choices, charge $450+distro costs+profit or move to a DIVX style scheme of charging a small base fee to get the media and then charging when you install packages from it. (Think RPM doing secure payment transactions for each installed package)
Now we start to see the problems with the proposed system. The development system is a large and complex, therefore expensive subsystem which few would pay to install. Oops! There goes your many eyeballs looking for bugs since nobody will be reading the source without an SDK to work with.
Of course precompiled standalone binaries become preferable to scripts because they would avoid paying for both the program and it's interpreter. Watch Perl, Python, etc fall in popularity in favor of less efficient to code/maintain but less expensive to execute C code.
And lets face it, it is not JUST the free speech aspect we like, the free beer is also a factor. HOw many of us have installed labs of computers from a single CD? Well kiss that goodbye, and with it one of the major competitive advantages.
Just having Freedom from Accounting is a major advantage in my book. Not having to carefully count licenses and make sure somebody hasn't installed an extra copy of Orifice somewhere. Somebody figure the economic drain imposed by all of that beancounting. Now this scheme proposes to take that beancounting to whole new levels of complexity and stupidity. Who decides whether a
hard to track down security fix is more valuable than a few feature?
Would anyone reading this want to live in the world I just described? I won't hold my breath waiting for a long stream of replies saying how happy people would be in such a world. So mark it up as yet another nice theory that made a wet smack when it ran into the Real World(TM).
COSS conflits with DFSG (Score:3)
I remember thinking of schemes like this when I first came across the idea of Free Software. I've been thinking about it ever since (about 14 years) and have concluded that they won't work. Given that I make my living out of supporting Free Software, this is not simply an intellectual exercise for me.
The problem is that people are generally not motivated to write good software by money. There is quite a body of evidence that offering monetary incentives to programmers tends to reduce quality, as the programmers start putting effort into working the system, rather than coding. Obviously, people are paid to code, but the money is rarely the direct motivation for doing a good job.
He does touch on one of the primary motivations for commercial programmers contributing to Free Software, which is that it is often cheaper to add the features you want to an existing Free program, than to write, or buy something else.
Anyway, an interesting article, but it's fundamentally flawed in its assumption that COSS falls under the wing of Free Software.
Clause 6 of the DFSG [debian.org] (a.k.a. OSD [opensource.org]) prohibits licenses that discriminate against specific fields of endeavour (such as making money, for example).
Even if that were not the case, DFSG compliant licenses must allow derived works (clause 2) which would mean that you could derive a work which differed only in the person to whom the money should be sent, which would instantly destroy the structure he's trying to build.
His ideas also seem to fall foul of the fact that you can do what the hell you like [uic.edu] with legally obtained software, so the ``are you using it enough to pay for it ?'' stuff might be interesting to enforce, and certainly wouldn't result in a DFSG license.
On the subject of allocating points, I'd be stunned if anyone could come up with a scheme that would appropriately reward someone that spends six months tracking down an obscure (but serious) bug (say an intermittent networking bug).
Say you allocate 5 points (it's only bug fix, after all) and the contributor says ``that's not enough, I spent six months finding that bug!'' --- You end up with all the silliness of having to do a clean-room reimplementation of the fix ? Oh dear, oh dear.
I disagree. (Score:3)
Your primary point of this article was that it does not cost money to distribute software. So once the r&d has been invested in the creation of the product.. distribution is unlimited and costs nothing! This leads to the conclusion that if OSS can produce software for free(dollars, not time here)... and distribute it for free, any such mutation will fail in the long-term.
OSS is indeed a gift culture, but it isn't as noble as you're portraying it - we do expect something in return. We expect our freedom.
--
Your COSS scheme is flawed (Score:3)
There are many possible frameworks for charging, most of which have also been tried by the closed-source software companies. For example:
I will never use any software that nickles and dimes me. I do not want any company or person knowing what software I use when. Also, as you mention, the value of a piece of software is different for each person. There are 400 individual software packages included in RedHat's distribution. What is the value to me of a single invocation of perl? Small. Very small.
Also, in the course of writing a perl script I will execute perl tens, hundreds, even thousands of times in testing it. What is the value of a single one of those perl executions? Zero. But much good may be derived from it if I develop a useful script. Development tools must not be charged for.
In implementation, your charging scheme looks like taxation. There are lots of good reasons that people hate taxation.
Open Source Software already has a problem with fragmentation. Human politics leads to disagreements, which leads to software splits (Net/Open)BSD, egcs/gcc, emacs/xemacs/lucid emacs, etc. By making it economically favorable for a contributor to grab the source and run, you make it favorable for the contributor to fragment the project. This is not a Good Thing(tm) IMHO.
In summary, it looks like an interesting idea, but totally unimplementable. You would have to create a central authority to handle "points", and this is wide open to fraud. I think one of the major strengths of Open Source is that it is economically free (beer). You would massively reduce the number of potential contributors to a project if now you must pay to hack it. "Many eyeballs" depends on a minimization of the effort involved in looking at the code. Once money is involved, you place a large stubling block in front of any potential set of eyeballs.
-- Bob
Sell your source (Score:3)
Commercial Open Source Software (COSS) would entail a commercial software vendor selling software licenses the same way they do now; however, they would also sell copies of the source code to their product. All users would still be required to pay the run-time license fee for the product, but modified versions of the software could be distributed (so long as the end users paid the license fee).
In addition, the author suggests that contributors to the source code might be paid for their contributions, and suggests a compensation scheme based on "contribution points." The company essentially outlines how many points a person gets for a contribution, (ie 1pt for a minor bug fix, 2pt for a minor/simple feature, etc.) and in return for contribution points, the contributor receives some revenue. The author suggests that these points should not be tradeable, to avoid alienation from the product and investment scams. Even if contribution points aren't a good way to pay contributors, the author still maintains that some mechanism should be provided for doing so.
My take on this is that the argument for selling your source is excellent. Many people believe that if anyone has a copy of a commercial vendor's source code then they will be unable to charge for it. This is pretty obviously wrong; we've seen a variety of cases where a sneaky hacker has busted in and liberated the source code to a variety of products, (the Quake source code was liberated in this way,) but the products made money anyway. This suggests to me that id could have easily have been distributing the source code to Quake, in c, and would not have suffered for it.
In addition, the author notes that the most expensive software is used by companies in the course of business. Managers who pay for software licenses take that payment out of their budgets; if they don't, they run the risk of employees blowing the whistle on a company when they see that the company endorses software piracy. This makes companies somewhat easier to monitor for software piracy.
Finally, many people want a packaged product, with manuals, tech support, and a pretty box; this can generally only be provided by buying a legal copy of the software.
Selling the source is a great idea, but what about contributors? Well, it's hard to tell whether and how contributors should be paid for contributions. In many cases, I think we'll find that contribution schemes like the one listed above will be unnecessary. It's unlikely that someone will decide to fix a bug in someone else's software in exchange for the meager sum that a company is likely to provide for that service. Many coders will be unwilling to contribute to COSS on the principle that it isn't Free. Coders still might do so for the prestige value, however; they might also do so if they get frustrated with a bug in the software and decide to go in and fix it themselves. So it seems to me that paying contributors won't add much to the contribution pool, and that contributors will still contribute source anyway.
The author's contribution scheme is especially flawed, IMO, because it could easily lead to feature bloat as programmers decide to code up lots and lots of minor features to try to get points. I also disagree with the author's claim that the points should not be made tradeable: it's hard to tell what would prevent the contributors from making contracts with others to accept a certain sum of money now in exchange for transferring all further contribution revenue to the buyer. While the author points out that trading leads to a whole body of rule/lawmakers who regulate investments, this is only another mark against contribution points.
In sum, COSS is a good idea. Giving contribution points in exchange for contributions probably isn't a good idea. However, some other mechanism of contribution might work, and might be necessary to develop a large body of programmers working on the project.
-Dan
Author doesn't get it. (Score:3)
Cygnus is a good example of a commercial free software company. They make their money developing and selling GPLed software.
The more I read stuff, the more I find that 'open source' is meaning 'free of charge' rather than anything else. I suppose this is even partly intentional, to hide any freedom issues. Amusing how 'open source' was supposedly coined to avoid this specific meaning, when this is the only meaning ESR presents.