Outsiders looking at free software tend to think that it is a kind of altruism or charity to make great software available gratis.
Some people are driven by a desire to, say, give good software to people in developing nations, or for students to have access to "the best software library in the world". That's well and good, but I think for most participants altruism is not the main motiviation. They want software freedom for themselves, and only secondarily for other people.
This is a good thing. If we were trying to persuade people to spend their evenings and weekends to write free software for the often-ungrateful general public, I don't know if we'd get very far. But if you can get people to do something that's fun, that produces a good result they can use themselves, and that incidentally improves the world, well... the results speak for themselves.
I don't know if I totally believe in the Invisible Hand theory that self-interest necessarily leads to good outcomes. The converse may be true though: most good things people do originate in some kind of self-interest, because most good or bad things people come from self-interest.
You can make a kind of evolutionary argument, however: In some societies, the behaviour caused by self-interest will tend to be constructive rather than destructive. Such societies tend to be more stable and to replicate.
[bonus Google serendipity: dissection
intelligent design creationist kook Michael Behe.]
Kent Beck did a talk at OSCon about Open Source as economic nonsense.
Shows Maslow's hierarchy of needs: survival, love, ... self-actualization. But I think he misinterprets it. Maslow indicates that beyond a certain point, getting more money (food, housing, etc)
The market for software is incredibly distorted. If you do something innovative, there's a big company north of here that will just squash you. Open source is a way of saying "hey, we're just not going to play this game."
I think I agree. Possibly if Microsoft declines and we get a more competitive and functional software market then the pressure for open source would decline a bit too. Microsoft like to talk about ecosystems; Linux in part is a reaction to that.
Reckons open source goes against trend towards accountability.
But open source also empowers users, letting them both get in touch with developers and also take control of things if they don't trust the developers.
If you're not getting enough accountability for free, pay money. Get HP or Red Hat premium support.
The whole thing is a bit like the argument that it's physically impossible for a bumblebee to fly. Satisfying yourself that you proved this doesn't make bumblebees fall out of the sky. It just indicates a problem in your theory.
Why does OS seem to work? We live in a land of plenty; people are willing to sacrifice basic needs to get higher needs met.
I think the core falacy here is that everything ought to reduce to money. Money is fine. However, making the maximum money is almost nobody's goal: people spend money on random things they enjoy, rather than saving every cent. People spend time goofing off in the evening when they could be working a second job.
People spend excess energy on programming rather than art, sports, community groups, poker, etc.
Well, true. Some people prefer programming to playing soccer. It's not for Kent Beck to say how people should spend their time.
Want to see whole people working whole jobs: both financially and spiritually rewarding. Options: sponsorship, patronage, pay-per-use, licensing, complements.
Well, balance is good. But if you can't get a perfect job, then it's a reasonable tradeoff to have a slightly tedious job and to do something more fun on evenings and weekends.
Money is a way of attracting people to do jobs they wouldn't do otherwise. That's why they call it money.
In the bigger picture, I don't care why IBM wants Java to be free software. Their motivations are their own. Mine are the same ones that have been my passion for nearly 14 years now: the ability to fix bugs that affect me, to add features I think are needed, to work on projects in cooperation with like-minded comrades, to avoid being locked in to any one company's view of the world. Personally I find APIs wonderful, but even good documentation is no substitute for an occasional (contamination-free) look underneath the hood.
My feelings are similar.
I feel a bit uncomfortable when I see news stories hyping Linux and free software as being more secure, cheaper, etc etc. It often is good in these ways but I don't think it is globally optimal. In any particular situation some closed software might well be a better solution for an immediate practical problem.
The trade press and the industry as a whole has this stupid habit of hyping things up to a ridiculous degree, then realizing how stupid they've been and swinging back the other way. So in a way I hate to see gushing articles about Linux because I think they will just make the recoil worse.
Anyhow: personally, I think it would be really nice to have a free system, with all the good aspects that Tom mentions. I think it is worth spending a little time to get it. It's not so important how many people want to use it, except if that helps it develop faster.
Plenty of thought, from William Gibson to Richard Stallman to Brad Cox has gone into two contradictory properties of information:
- Information can be valuable.
- Information wants to be free.
"Wants to be free" means that it tends to leak out, despite your best efforts. If it's a secret, it will be told. Even if you keep it secret, people might infer the information from your actions. If it's proprietary, it'll be copied. If it's protected, it will be cracked.
There's something a lot like thermodynamics going on here. Everything eventually collapses to waste heat. It's all about what work you can extract from the process while that's happening.
[work in progress; comments solicited]
Back in the mid 90s, one would regularly read about the Future of Software being something like this: when you want to build an application, you find, licence and assemble a whole bunch of components from individual software vendors. You plug them together, according to well-defined interfaces, perhaps write a few high-level components of your own, and deliver the whole assembly the the customer.
Stop selling software. Give it away. Get paid for its use. Meterware is so logical it could be the foundation of the new, networked economy.[...]
Treating ease-of-replication as an asset rather than a liability, superdistribution actively encourages free distribution of information-age goods via any distribution mechanism imaginable. It invites users to download superdistribution software from networks, to give it away to their friends, or to send it as junk mail to people they've never met.
Why this generosity? Because the software is actually "meterware." It has strings attached, whose effect is to decouple revenue collection from the way the software was distributed. Superdistribution software contains embedded instructions that make it useless except on machines that are equipped for this new kind of revenue collection.
Superdistribution-equipped computers are otherwise quite ordinary. They run ordinary pay-by-copy software just fine, but they have additional capabilities that only superdistribution software uses. In Mori's prototype, these extra services are provided by a silicon chip that plugs into a Macintosh coprocessor slot. The hardware is surprisingly uncomplicated (its main complexities being tamper-proofing, not base functionality), and far less complicated than hardware that the computer industry has been routinely building for decades.
Electronic objects intended for superdistribution invoke this hardware, which provides instructions. These instructions check that revenue-collection hardware is present, prior usage reports have been uploaded, and prior usage fees have been paid. They also keep track of how many times they have been invoked, storing the resulting usage information temporarily in a tamper-proof persistent RAM. Periodically (say monthly) this usage information is uploaded to an administrative organization for billing, using encryption technology to discourage tampering and to protect the secrecy of the metered information. (Think of your utility bill.)
To get there, we would have needed a few things. Firstly, new technologies that allowed programs to be reliably assembled at run time from component libraries. This is more than just dynamic linking: you need to think about finding the right components, versioning, making state persist, and so on. Given the processor speeds of the time, they needed to be (mostly) native binaries, rather than some kind of bytecode. The technologies here include things like OS/2's SOM, COM, Objective C, and so on. Most of these use a kind of looser linking than we normally have with C, in an attempt to allow the libraries to evolve without breaking the applications.
Secondly, you need an economic model to support it. If people are going to publish and sell small component libraries you need a way of licensing them and a way of arranging payment. If the components are going to be very fine-grained, this converges on almost a kind of micro-payment system, particularly if you want per-use licensing.
I find this really fascinating because it's so close, and yet so far, from what we have in free operating systems. A free Unix system is built from components written by many individual and independent programmers, which are in turn assembled by other people. Possibly there are several layers of assembly: subsystem maintainers knit up all the parts of the USB Storage system, which is in turn assimilated by somebody else into the USB system, which Linus merges into the kernel, which somebody else patches for optimal desktop performance, and that is in turn only one part of the distribution.
Despite the similarities, free software seems to be proving that the Superdistribution model is fundamentally wrong.
Putting code into binary, closed libraries, just doesn't work very well. At least, it works far less well than open source libraries. It ignores some fundamental properties of software: that defining interfaces and documenting behavior is as hard or harder than implementing the behavior. Even if you never change the source, having read access to it as the ultimate documentation is incredibly useful. Eric Raymond has a good discussion of the problems with binary libraries in his book The Art of Unix Programming.
Even assuming the library has good test coverage by the publisher, it will always hit situations in the real world that weren't contemplated, especially when it's put into a complex ecosystem of other components. Testing and documentation can't cover every conceivable use.
As if binary libraries weren't bad enough, Cox suggests that the components need to be subject to DRM to protect the revenue stream of the author. We need new hardware, a la Paladium. This makes sense within his economic model, but consider how horrible it would be to use. “Protecting” the code would probably require that it be kept shrouded and encrypted: not only is there no source for the application developer, but probably not even any ability to use a low-level debugger. And just think about the bugs DRM can introduce. Pay per use requires some amount of DRM, but DRM from the user's point of view makes the components strictly worse. At most it is tolerable; at worst it blocks the project entirely.
As an example of strong DRM: I'm quoting some of Cox's writing above. How should I arrange payment for this quotation? How should I arrange for you the reader to pay him for reading 10% of his essay? Why should I give up emacs and Mozilla in favor of tools that restrict my ability to copy and paste? (I think Xanadu was trying to charge by the byte, and who uses Xanadu?)
So: Stop selling software. Give it away. Work out some other way to make money, because pretending it's not replicable is not it. Profit.
Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May
Copyright (C) 1999-2007 Martin Pool.