After the Software Wars (Part 1)

[UPDATE:  Keith’s take on my review so far is in Comments below.]  At last, my review of Keith Curtis’s After the Software Wars.  The book covers a lot of material, including Curtis’ ideas about standardization and a new, uniform programming language (and some unfortunate off-topic right-wing diatribing at the end – nothing deflates an intellectual argument like a quote from the Coultergeist), but I’m going to focus on the open source material.  This is part one of two as I’m up to 8 pages!

One of the topics I’d label the “Historical Inevitability” argument, i.e. that software will be free because there is a great, unstoppable movement away from paid content.  Statistics certainly support the fact that more people use Linux now, and more people are downloading free software in general (either freeware, shareware or pirated) than they did before.  But the idea that this is automatically going to lead to universal free code doesn’t flow for me, for a number of reasons.

Economics

Curtis talks about how free software gets made, mostly through the “surplus intellectual energy” of those who either create paid software at their day jobs or support it in some function.  There is a momentum argument, that “the more people using free software, the more applications will be built for it.”  He argues that “Free software will be built because it is so valuable to businesses, but everyone else will just come along for the ride and get it for free,” and that “While free knowledge and free software are not any direct goal of the free market, they provides tremendous benefits to the free market because they allow anyone to create further value.”

So the argument has a sound economic first premise – things will be made because they are needed.  But from there, the economics get weaker.  If things are needed, and have value, human beings generally want to be compensated for the evolutionary triumph of meeting a need.  And economies of scale become involved.  Curtis gives as much text to “fame” as a motivator as to money, which may be true in some endeavors, but there are a limited number of people willing to sacrifice economic self-sufficiency for coolness, and a limited number of glamorous achievements for which fame can be achieved amongst all the gruntwork involved in coding day-to-day solutions.

Free software on the microeconomic scale is doable, as Curtis explains when he discusses “copyleft”:

There is no free lunch in this world, and copyleft ensures that people are giving back to this free software…Free software is not expensive because, in practical terms, advancements in software are nearly always based on existing knowledge and are very small in scope. What you must give back is much smaller than what you have freely received.

I.E., the “gift” in kind is not, in terms of time or effort, more than you would spend on paid software.  So the economic model is sound because everyone working on the project is making “micropayments” into it in expectation of the reward of the finished product and its usefulness.  Value is given for value received. 

But on a macroeconomic level, this model doesn’t scale.  For instance, what motivation are we hoping to find in a person or group who writes a sophisticated SAP-style package?  They are definitely providing “tremendous benefits to the free market” because they allow GM or Microsoft to stop paying SAP a trillion dollars for business management software, but who dreams of saving GM money so ardently that it becomes such a passion that they spend their free time making it happen?  Curtis argued in his email to me, arguments that need to be punched up in the text of the book, that services will provide the profit motive to developers and subject matter experts – but consider the risk involved in creating a business package in the hopes that you, and not someone working for literally 1/100^th the price in India, will get the work.  The economic motivation in creation is that you are the only one who can do what you do, whereas once the work is created, anyone in Bangalore can learn it (especially if the code and documentation is completely open source), become a SME, and eat your lunch. 

Now, I work in services in my “moonlight” job – I do training and training materials for a federal government software package (CAREWare) which HRSA gives for free to HIV/AIDS agencies around the country, which they can use to track all the standards of clinical and social care for which they’re funded, and report back in ready-made government forms/reports.  It’s not technically open source, as the government pays the programmers, but it’s free to anyone who wants to use it.  Since it’s a niche market, and since I’ve worked with it both in an HIV agency and as a consultant for many years now, I’ve got a good slice of the consulting services (HRSA pays me, sometimes state health departments, more rarely individual agencies).  And this isn’t the kind of thing which just anyone abroad can underbid me on, because it requires a specialized skill set (deep knowledge of the program, knowledge of HIV/AIDS, long familiarity with past and current standards of care and reporting requirements, etc.) and a lot of hands-on/hand-holding onsites.  But this is still a microeconomic deal in that the needs, while critical, are relatively small enough that only a few consultants in the country are needed.  So I see services as an opportunity to make a good living in the open source world, but only in specialized markets where competition is limited.

Working in a closed system (i.e. with proprietary code for which you need a fistful of MCSEs to get hired) remains appealing to a significant portion of talent because it guarantees you get to eat your own lunch – arguably, not forever, if the closed system gets superseded by a better free product, but as Harry Hopkins said during the Depression, “People don’t eat in the long run, they eat every day.”  And food (Eben Moglen’s magical loaf of bread aside) costs money, which has to be earned.

Curtis uses the example of an MRI machine as something that can benefit from open source:

One of the reasons an MRI machine is expensive is because the software is proprietary. When a hardware vendor controls the software, it can set the price at the cost of the hardware plus the cost to develop the software, rather than something approximating their hardware costs. If MRI software were free, the hardware cost would drop, more people could afford them, and the quality would increase faster. 

But you can’t code an MRI at home, in your spare time.  Programmers have to work on the machine on site to test the software.  Are people going to volunteer to come into the hospital for six months to create it?  How will they survive in the mean time?  Will the hospital let just anyone come into the hospital to work on it? Unless we’re abolishing all trade secrets, won’t the manufacturer of the machine be reluctant to publish the specs on the web to enable better programming, if that also means enabling a factory in China to duplicate their machine?

And even given a “fee for service” model, so to speak, for the programmers who’ve coded for free, what happens to the hospital when it meets this situation with its volunteers coders who are working for service and support fees?

I met an IT employee in a hospital who felt that after her hospital had purchased some software, their vendor became unresponsive.  Their vendor had made all their money and had no motivation to help the hospital anymore. The hospital fought with their vendor about whether the enhancements they were requesting were bugs, which would be fixed quickly and for free, or features, which would cost money and weren’t guaranteed to be fixed for a year or more.  To the hospital, this distinction was irrelevant: lives were on the line, and they wanted improvements, and they didn’t care how their software vendor categorized them!

The fact that the software is free doesn’t change the fact that there will always be a limited number of people who have mastery of the subject matter, and even fewer within that group who are available at any given time to consult.  So even in a free software environment, costs for new features or “implementation” can still escalate the overall costs.

Finally, I think it’s critical that we don’t ignore The BGE (Bullshit Guy Effect) – Linux is doing a good thing by offering certification programs, equivalents to the MCSEs which companies rely on, for better or worse, to validate someone’s skills.  But when free software proliferates, how can you certify everyone on everything?  The Bullshit Guy is the guy who knows enough to get his foot in the door, to get through an interview or land a contract with smooth patter, a sharp suit, and command of enough Standard American Bizbull to snow the people who, not being able to understand the complexities of the software themselves, are responsible for hiring him.

You can argue that “the magic of the market” purges BGs, but it doesn’t – people who don’t know software are the same as people who don’t know drywalling or plumbing and go to the phone book to find someone who does; when they get burned, the trust level available to honest consultants, contractors, plumbers etc. deteriorates.  You have to know a guy who knows a guy, to get good service – in other words, you have to already be in a system in order to successfully join it (catch 22).  The “value” of scamming suckers remains so high, because the majority of consumers for everything from illegal steroids to complex software can’t determine if your product is real or not until after they’ve been burned, and with the proverbial sucker born every minute, the “magic of the market” doesn’t purge the bottom feeders as long as there is a profitable bottom.  Catch 22 part 2:  Only in an ecosystem of perfectly educated consumers can the fakes be purged, and yet the perfectly educated consumer doesn’t need a service consultant. 

So you’re always going to end up with a handful of low maintenance, “trusted brands” of software, free or not, because people don’t like excessive risk.  Let a thousand flowers bloom – only a couple will survive, because too much choice overwhelms the consumer.

What other economic incentives are there?  The idea that donations will form “sufficient incentive to create” has been tested with shareware – how’s that worked out?  How many people download and what percentage of people actually pay? Curtis provides the answer:

 Drupal is a piece of free elegance to help manage the content of a web site. Like many software projects, it has a link where you can donate money via PayPal. While Drupal had 45,000 users in 2006, it received only $1,000 in donations, for an average donation of 2 pennies per person.

One idea Curtis provides for incentivizing is that of bounties for those who can solve certain software problems, like mini-X Prizes.  The problem of course becomes that someone has to donate the bounty, and aside from a handful of billionaires, prizes for big scientific achievements are thin on the ground.  (Bill Gates and/or Microsoft could get a huge PR boost by sponsoring such prizes for both MS and open source problems.)

Advertising revenue is offered as incentive as well: 

Your free photo management tool could enable printing by default to Kodak machines over the Internet and the creator of the photo management tool could get a cut of the printing fees. Widespread use of free software will create new opportunities to extract value when appropriate. 

It’s not a bad idea, unless Kodak decides they don’t like your blog and don’t want to be associated with you, or you have to wend your way through their Marketing department to convince them you’re leveraging synergy that energizes the brand blah blah blah, then their legal department, etc. 

In part two, I’ll discuss the Idealism side of the open source movement, and Curtis’ take on the economics of art in a “free culture.”