Early Perspectives On Open Source
Years back — in the ancient Web 1.0 world of 1997, whenSlashdot was just beginningto enter the geek consciousness — I became embroiled in animpassioned debate with a peer, arguing the relative merits ofopen/free software versuscommercial/pay software.
Flurries of emails rained over our respective groups, as wefought to evangelize and fortify our positions, building bunkersof suppositions and hyperbole.
At the time I was a fervent admirer of Microsoft and theirWays — a position that lead to endless accusations that I wasa covertly paid astroturfer for the so-called Evil Empire — not tomention that I was, and remain, a true believer in the capacity forfinancial incentive to encourage innovationand product excellence.
I also rather enjoy the software development profession, and it wouldn’t beuntrue to say that my position was partly driven by defensiveness,motivated by a fear that open-source software, and the accompanyingideology and fanatical advocacy, undermined my professionalexistence.
The Face Of Open Source Evangelism
My opponent, in contrast, was a GPL-embracing, Linux-advocating,Microsoft-hating, Stallmanesquesort. He’d finger through his unkempt beard (where one would expectto find stray noodles from a prior meal), and after trying toconvince anyone listening that recompiling one’s kernel withdrivers specific for the target environment was an idealarrangement, he’d tear into the evils of closed source commercialsoftware, passionately arguing that closed source, along withintellectual property hoarding, was a moralsin.
We debated the merits of “free as in beer” and “free as inspeech” software, with him arguing that many software solutionswere so ubiquitous and prevalent, and so easily replicated, thatthey no longer merited payment or intellectual protection: Innovation in that realm was no longerdriven by capitalist forces, but instead arose from scratch-an-itchneeds.
Everyone would benefit, he advocated, if we all contributed tothe global software pool, and we could all pull out what we need, receiving”payment in kind” by way of other people’s contributions. If wefound an edge/exception condition that the software couldn’thandle, or a missing feature that would solve our need, we couldcode it in and contribute back.
In essence a sort of softwaresocialism.
The particular example we continually debated concerned basicsystem functionality, specifically that kernel services had been sothoroughly fleshed out, and were so similar across vendors, thatwe’d reached the point where the foundational operating systemshould be free as in beer, and more importantly free as in speech.With the basic infrastructure accounted for and implemented well(albeit constantly evolving as people scratch their itches, andhardware vendors implemented enhancement to leverage new products),organizations across the land could focus their financial and humanresource efforts higher in the software ecosystem.
This was just one example, and he held the same opinion for awide range of system services and development libraries.
All of the big retailers, for instance, could leach off of anopen source point of sale system, running on an open sourceplatform, hiring help to customize it to their needs, and thencontributing their changes back to benefit others.
The Benefits of Open Source
Win/win for everyone: Retailers got a customized POS system for”nothing“(presuming that evaluations, implementation, and maintenance werefree, but ignore those silly nuances) — to most retailersthere is no strategic advantage to using a different POS systemthan competitors — which they could customize limitlessly;Customers win because of reduced overhead in the infrastructure,theoretically leading to lower prices; Developers/IT-types winbecause they get hired on for customization and support, and theyhave the ability to have as much “inside knowledge” of the productas anyone else (versus a product like SAP, where only those insideSAP have the ability to have complete knowledge of the product,leaving everyone perpetually a step behind), not to mention that ashop will be more open with their wallet, presumably, when theydon’t have to pay several million dollars to a software vendor.
We’d save the carrot of wealth — the argument went– to entice those developers truly pushing boundaries, orgain from the development of large corporations with specific needs(“itches”) that would also benefit the overall community, ratherthan paying tithe to yet another Lempel-Ziv implementation orscorecard system or multitasking kernel, or for yet anotherreworking of the system services to benefit some up-and-coming newproduct from the same organization.
And anyways, those people who did contribute to thefree-software ecosystem were rewarded in kind by improvements andextensions of what they have done, along with all of the othersoftware they could utilize and leverage.
Seeing the Light…Or At Least Catching A Glimpse
At the time I thought he was nuts, or at least irrationallyidealistic.
Not only is it a grossly unbalanced system, where there aremagnitudes more consumers than there are creators,but more importantly it seemed to de-professionalize softwaredevelopment: Under the universal implementation of this sort ofsystem, developing software, with software as the product, wouldn’tbe something that could put food on the table and a roof over one’shead, not to mention pay the car loan, put the kids throughuniversity, and fund a retirement.
Software development would be limited to hobbyists, parentalbasement dwellers, and professors attached to theacademic teat, disconnected from financial reality. Theguy with calloused fingers and tired brain, exhausted aftermonths creating the next open source wonder, barely has a legup on every johnny-come-lately that appears and offers support andconsulting on their creation.
It didn’t seem tenable, or sustainable.
To be honest, I was sure that the whole open source thing wouldfizzle out, apart from a couple of large corporate projects run ina traditional manner, releasing source purely as a PR move.
As the years have passed, and my knowledge and the market itselfhave matured, however, I’ve been moved more and more to the pointof finding myself agreeing with parts of his argument.
Not all of it, though.
I still think the GPL is a wolf in sheep’s clothing. I stillthink the “support” financing angle is laughable for all but thelargest, most enterprise-friendly of vendors. Istill think the Cathedral andthe Bazaar paper is wishful thinking, and is a model that islargely unseen in most open source projects. I still think theoverwhelming majority of open source software — following thewhole power law distribution thing — see little source codeattention beyond that given by the direct developer(s), with manyprojects abandoned after the initiator fails to see the Linux-likeattention she expected. I still think that “it’s securebecause the source is available!” is ridiculouslynaïve, hinting at a bit of hopefuldenial. I still think the simplistic idea that having thesource code (such as to the Linux kernel) automatically correlateswith being able to actually effectively do somethingwith it hints at a complete lack of experience insoftware development, where people underestimate the project anddomain knowledge required to effectively make use of source beyondchanging some label constants. I still think many of the largecorporate cheerleaders of open source are exploiting the movement,getting software for their expensive, overpriced, proprietaryand patent protected hardware on the backs of a bunch ofhobbyists, while offering remarkably little in return. I stillthink many successfulopen source projects are largely just traditional softwareproducts, with a core group of paid individuals who are responsiblefor the vast bulk of the implementation, and the project justhappens to have source code available.
I still think that “proprietary” closed source systems have asignificant role to play, and that a lot of the innovation in themarket happens because someone is chasing a dollar, and theneveryone falls in line behind.
Even in open source, capitalism motivates a large number ofprojects as developers imagine great support and consultingcontracts just around the bend, or the increased ability tomonetize their reputation.
Free As In Beer
Yet frequently I’m finding myself asking “you actually wantmoney for this simple hackjob?“
This is especially true in the Microsoft-ecosystem developmentmarket: Where the PHP, Perl and Python worlds have powerful,complex, free (both in terms of availability of source code andmonetary cost) components and modules covering virtually everyneed, one often finds that even the most trivial .NET componentinclude demands for often significant sums of money, not to mentionarduous and annoying licensing and compliance requirements, oftenbundled in a warm nest of layers of IP protections andredistribution requirements.
Which brings up a critical point — Even ignoring the upfrontcost, software licensing is a major PITA. Add in some hack-jobactivation scheme or machine lockdown, and you’ve made me paranoidthat a simple hard drive failure or system migration is going tocause major hiccups of administration. Suddenly I have to worryabout endless dependencies and additional costs for every developeradded on the team, with even casual consultants suddenly needingmultiple licenses — and related activations — tocompile with the tab component or the grid component or the POP3component.
What a nuisance. Sadly this sort of commercial software overheadis only getting worse as time passes.
So even where I don’t care for the source code or itsavailability, and I don’t care about the upfront costs, I’mbeing drawn to free-gratis software where the need in question isrelatively trivial or long proven. It’s not that I’m adverse tocommercial software — I most certainly am not — but there is alimit to its exploitation.
From FreeBSD appliancesto 7-zip to the GIMP to JAlbum to JDiskReport tothe many free online services. Access to the sourcecode is anicety, and in some cases is critical, and I alwaysdemand trustworthiness of the software in question anyways, howeverit really is the gratis element that’s most important to me (as itis for many people, though they mask that simple reality under acloak of open-source camouflage), because it often comes withextremely liberal usage requirements.
Doesn’t This Hurt Developers?
Naturally many developers will gasp in horror at the idea ofreplacing commercial software with free software. Their naturalopposition –and this was the root of my original defensiveness –is the idea that such an action leads toa contraction of the software developmentfield, basically putting ourselves out of business as more and moreof our bread and butter disappears.
“If you aren’t paying the Microsoft tax“, they argue,”you’re dooming us all!“.
Nothing could be further from the truth. The Microsoft tax couldbe what’s dooming us all.
Again sticking with Microsoft as an example, given their sizeand importance, every developer not working at Microsoft — whetherthey work for a competitor or for a small IT shop — needs toremember that Microsoft’s eventual goal is to put every oneof them out of work. If Microsoft could convince everyorganization to pay them $10,000 per head per year, and they’d getmagically adapting and accomodating, infinitely flexible systemsrunnable by a minimum-wage temp, they would.
Microsoft is endlessly putting out feelers to determine whatshops are paying developers to make, and then they’re trying tobuild wizard-filled, manager-friendly solutions to accommodate thatneed (for a small fee…). The sales pitch, of course, isa barely concealed statement that you can dump that developer, orat least replace them with someone much less skilled, thereforeless expensive.
You know that clever Microsoft ad where the IT department islearning line dancing, given how much easier the new server versionis to administer, thus giving them lots of free time? Really it wasa not-so-subtle message directed at Vice Presidents — Here’s a wayto chop the headcount, putting some people out of work. Just payMicrosoft the not insubstantial cost of $X across your enterprise,and you can save $Y. Even if $Y is lower than $X, capital costsalways look “cheaper” on the financials than human resourcescosts.
How about the Total Cost of Ownership comparisons,where Microsoft proudly shows that the TCO of Windows iscomparable, or slightly lower than, Linux for certain needs. Theydo this by minimizing manpower needs and skill requirements,meaning that you pay more to Microsoft for all of those serverlicenses and client access licenses, and then you can pay a littleless to employees.
It doesn’t sound quite as inspiring from such a perspective.When you really step back and look at it, and realize thatMicrosoft — or any one software vendor for that matter, and I’mnot intending to pick on Microsoft but to use them as an example –doesn’t have interests that are necessarily aligned with yours, Mr.uISV or corporate IT worker bee or consultant, it starts toseem more and more bizarre how defensive many professionalsoftware developers are about Microsoft relative to open sourcesource. How bitterly they complain about open source, feeling thatevery win for Linux or Apache of Firefox threatens their ownfuture.
Efficiency Benefits Us All
None of this is to say that efficiency isn’t important — it’scritically important: When I buy a loaf of bread,or shop at a grocery store, or buy a car, it’s to my benefit forthose organizations to do everything they can to minimize costs,even if that means leveraging systems that make some of theirworkforce unnecessary. So if Microsoft can throw together a costeffective Biztalk Infopath Sharepoint Portal.NET Server2007 that eliminates the need for a signficiant percentage ofcustom development across the land, then that benefits everyone(well…apart from those directly affected — the people directlylosing the jobs).
We all get a little bit more for a little bit less.
The critical point I’m trying to make, however, is that from apersonal perspective the argument is not, and has neverbeen, free software -or- commercial software. In fact manycommercial software ventures can be helped by the costsavings of free software (presuming that there aren’t licenseconflicts). Your solution looks a lot more palatable when itleverages a stack of free, well-known software, versus requiring acomplex mix of server systems and expensive third-partysoftware (we once considered a solution that would have sold forless than $500, yet would have necessitated about $4000 ofMicrosoft software). Your IT team looks a lot more cost effectivewhen the shop isn’t spending millions of dollars a year maintainingvarious Software Assurance plans, spending tens of thousands onvarious marginally useful software products per developer head.
It’s hardly surprizing that many of the “Web 2.0” successstories started out on, and then scaled up with, open sourceplatforms: Their beginnings weren’t hobbled by software fees thatexceeded the yearly take of the founders, and they could scaleout cost effectively given they didn’t require endless CPUlicenses, client access licenses, and component fees.
From a personal perspective, I still build solutions largely forthe Windows platform, often using integrated technologies such as.NET, ActiveDirectory, and IIS, while leveraging servers such asSQL Server and Biztalk. Yet I do so from a very pragmatic,looking-out-for-#1 perspective — If I could reasonably justifyswitching to a free platform, I would. I owe no duty to Microsoftto keep their revenue stream padded.
How This All Came About
Recently I had the need to receive some PGP encrypted files on aserver, which necessitated the ability to decrypt them from ascript. Seemed pretty straightforward, especially given that I wasdoing something very similar with PGP freeware over a decadeago.
“Uh oh,” I though. “here comes the ubiquitousserver tax.” (the server tax is the fact that commercialsoftware, no matter how trivial, have a propensity tobizarrely cost much if it runs on a “server”). I headed over toPGP and took a look at thecommandline version.
This is, in essence, just a slightly updated version of thefreeware PGP circa 1995, so I wasa little surprized by the price (not to mention the nonsensicalsales criteria — you can buy send only, received only, or thesuper-deluxe send and receive. You can also choose to useonly 1 key, or many keys. All ridiculous separations that just leadto implementation nonsense and complexity). At the time of writing,the component in question costs a staggering $3,170.
Maybe it’s “chump change” for a large enterprise, where suchcosts get buried under thousands of similar purchases, but thesesorts of licenses — not to mention the administration andhassle of them — add up. They come out of the general IT pot,meaning less hires, less bonuses, more cost-efficiency pressure,and so on.
I went and grabbed a copy of GNUPG, and found that it immediatelyfit the need perfectly. The code is modern, and it is fullycompatible with OpenPGP implementations. I can use 1, 10, or 100keys with no additional costs. I can run 1 instance or 100instances if I want. I can send and receive. I never have to hasslewith licensing issues, beyond of course ensuring that code changes(given that I legally and immediately get the source code) that aredistributed conform with GPL requirements.
The total implementation cost, especially after consideringpurchasing and licensing issues (e.g. none), was dramatically lessthan the commerical offering, offering every bit of functionalitywe needed (and then some), leaving that money in the pot for otherneeds. We have the added comfort of being about to plan massivescale-outs with minimal additional cost, increasing the project’sversatility and flexibility.