Years back -- in the ancient Web 1.0 world of 1997, when Slashdot was just beginning to enter the geek consciousness -- I became embroiled in an impassioned debate with a peer, arguing the relative merits of open/free software versus commercial/pay software.
Flurries of emails rained over our respective groups, as we fought to evangelize and fortify our positions, building bunkers of suppositions and hyperbole.
At the time I was a fervent admirer of Microsoft and their Ways -- a position that lead to endless accusations that I was a covertly paid astroturfer for the so-called Evil Empire -- not to mention that I was, and remain, a true believer in the capacity for financial incentive to encourage innovation and product excellence.
I also rather enjoy the software development profession, and it wouldn't be untrue to say that my position was partly driven by defensiveness, motivated by a fear that open-source software, and the accompanying ideology and fanatical advocacy, undermined my professional existence.
My opponent, in contrast, was a GPL-embracing, Linux-advocating, Microsoft-hating, Stallmanesque sort. He'd finger through his unkempt beard (where one would expect to find stray noodles from a prior meal), and after trying to convince anyone listening that recompiling one's kernel with drivers specific for the target environment was an ideal arrangement, he'd tear into the evils of closed source commercial software, passionately arguing that closed source, along with intellectual property hoarding, was a moral sin.
We debated the merits of "free as in beer" and "free as in speech" software, with him arguing that many software solutions were so ubiquitous and prevalent, and so easily replicated, that they no longer merited payment or intellectual protection: Innovation in that realm was no longer driven by capitalist forces, but instead arose from scratch-an-itch needs.
Everyone would benefit, he advocated, if we all contributed to the global software pool, and we could all pull out what we need, receiving "payment in kind" by way of other people's contributions. If we found an edge/exception condition that the software couldn't handle, or a missing feature that would solve our need, we could code it in and contribute back.
In essence a sort of software socialism.
The particular example we continually debated concerned basic system functionality, specifically that kernel services had been so thoroughly fleshed out, and were so similar across vendors, that we'd reached the point where the foundational operating system should 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, and hardware vendors implemented enhancement to leverage new products), organizations across the land could focus their financial and human resource efforts higher in the software ecosystem.
This was just one example, and he held the same opinion for a wide range of system services and development libraries.
All of the big retailers, for instance, could leach off of an open source point of sale system, running on an open source platform, hiring help to customize it to their needs, and then contributing their changes back to benefit others.
Win/win for everyone: Retailers got a customized POS system for "nothing" (presuming that evaluations, implementation, and maintenance were free, but ignore those silly nuances) -- to most retailers there is no strategic advantage to using a different POS system than competitors -- which they could customize limitlessly; Customers win because of reduced overhead in the infrastructure, theoretically leading to lower prices; Developers/IT-types win because they get hired on for customization and support, and they have the ability to have as much "inside knowledge" of the product as anyone else (versus a product like SAP, where only those inside SAP have the ability to have complete knowledge of the product, leaving everyone perpetually a step behind), not to mention that a shop will be more open with their wallet, presumably, when they don'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, or gain from the development of large corporations with specific needs ("itches") that would also benefit the overall community, rather than paying tithe to yet another Lempel-Ziv implementation or scorecard system or multitasking kernel, or for yet another reworking of the system services to benefit some up-and-coming new product from the same organization.
And anyways, those people who did contribute to the free-software ecosystem were rewarded in kind by improvements and extensions of what they have done, along with all of the other software they could utilize and leverage.
At the time I thought he was nuts, or at least irrationally idealistic.
Not only is it a grossly unbalanced system, where there are magnitudes more consumers than there are creators, but more importantly it seemed to de-professionalize software development: Under the universal implementation of this sort of system, developing software, with software as the product, wouldn't be something that could put food on the table and a roof over one's head, not to mention pay the car loan, put the kids through university, and fund a retirement.
Software development would be limited to hobbyists, parental
basement dwellers, and professors attached to the
academic teat, disconnected from financial reality. The
guy with calloused fingers and tired brain, exhausted after
months creating the next open source wonder, barely has a leg
up on every johnny-come-lately that appears and offers support and
consulting on their creation.
It didn't seem tenable, or sustainable.
To be honest, I was sure that the whole open source thing would fizzle out, apart from a couple of large corporate projects run in a traditional manner, releasing source purely as a PR move.
As the years have passed, and my knowledge and the market itself have matured, however, I've been moved more and more to the point of 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 still think the "support" financing angle is laughable for all but the largest, most enterprise-friendly of vendors. I still think the Cathedral and the Bazaar paper is wishful thinking, and is a model that is largely unseen in most open source projects. I still think the overwhelming majority of open source software -- following the whole power law distribution thing -- see little source code attention beyond that given by the direct developer(s), with many projects abandoned after the initiator fails to see the Linux-like attention she expected. I still think that "it's secure because the source is available!" is ridiculously naïve, hinting at a bit of hopeful denial. I still think the simplistic idea that having the source code (such as to the Linux kernel) automatically correlates with being able to actually effectively do something with it hints at a complete lack of experience in software development, where people underestimate the project and domain knowledge required to effectively make use of source beyond changing some label constants. I still think many of the large corporate cheerleaders of open source are exploiting the movement, getting software for their expensive, overpriced, proprietary and patent protected hardware on the backs of a bunch of hobbyists, while offering remarkably little in return. I still think many successful open source projects are largely just traditional software products, with a core group of paid individuals who are responsible for the vast bulk of the implementation, and the project just happens to have source code available.
I still think that "proprietary" closed source systems have a significant role to play, and that a lot of the innovation in the market happens because someone is chasing a dollar, and then everyone falls in line behind.
Even in open source, capitalism motivates a large number of projects as developers imagine great support and consulting contracts just around the bend, or the increased ability to monetize their reputation.
Yet frequently I'm finding myself asking "you actually want money for this simple hackjob?"
This is especially true in the Microsoft-ecosystem development market: Where the PHP, Perl and Python worlds have powerful, complex, free (both in terms of availability of source code and monetary cost) components and modules covering virtually every need, one often finds that even the most trivial .NET component include demands for often significant sums of money, not to mention arduous and annoying licensing and compliance requirements, often bundled in a warm nest of layers of IP protections and redistribution requirements.
Which brings up a critical point -- Even ignoring the upfront cost, software licensing is a major PITA. Add in some hack-job activation scheme or machine lockdown, and you've made me paranoid that a simple hard drive failure or system migration is going to cause major hiccups of administration. Suddenly I have to worry about endless dependencies and additional costs for every developer added on the team, with even casual consultants suddenly needing multiple licenses -- and related activations -- to compile with the tab component or the grid component or the POP3 component.
What a nuisance. Sadly this sort of commercial software overhead is only getting worse as time passes.
So even where I don't care for the source code or its availability, and I don't care about the upfront costs, I'm being drawn to free-gratis software where the need in question is relatively trivial or long proven. It's not that I'm adverse to commercial software -- I most certainly am not -- but there is a limit to its exploitation.
From FreeBSD appliances to 7-zip to the GIMP to JAlbum to JDiskReport to the many free online services. Access to the sourcecode is a nicety, and in some cases is critical, and I always demand trustworthiness of the software in question anyways, however it really is the gratis element that's most important to me (as it is for many people, though they mask that simple reality under a cloak of open-source camouflage), because it often comes with extremely liberal usage requirements.
Naturally many developers will gasp in horror at the idea of replacing commercial software with free software. Their natural opposition --and this was the root of my original defensiveness -- is the idea that such an action leads to a contraction of the software development field, basically putting ourselves out of business as more and more of 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 could be what's dooming us all.
Again sticking with Microsoft as an example, given their size and importance, every developer not working at Microsoft -- whether they work for a competitor or for a small IT shop -- needs to remember that Microsoft's eventual goal is to put every one of them out of work. If Microsoft could convince every organization to pay them $10,000 per head per year, and they'd get magically adapting and accomodating, infinitely flexible systems runnable by a minimum-wage temp, they would.
Microsoft is endlessly putting out feelers to determine what shops are paying developers to make, and then they're trying to build wizard-filled, manager-friendly solutions to accommodate that need (for a small fee...). The sales pitch, of course, is a barely concealed statement that you can dump that developer, or at least replace them with someone much less skilled, therefore less expensive.
You know that clever Microsoft ad where the IT department is learning line dancing, given how much easier the new server version is to administer, thus giving them lots of free time? Really it was a not-so-subtle message directed at Vice Presidents -- Here's a way to chop the headcount, putting some people out of work. Just pay Microsoft the not insubstantial cost of $X across your enterprise, and you can save $Y. Even if $Y is lower than $X, capital costs always look "cheaper" on the financials than human resources costs.
How about the Total Cost of Ownership comparisons, where Microsoft proudly shows that the TCO of Windows is comparable, or slightly lower than, Linux for certain needs. They do this by minimizing manpower needs and skill requirements, meaning that you pay more to Microsoft for all of those server licenses and client access licenses, and then you can pay a little less to employees.
It doesn't sound quite as inspiring from such a perspective. When you really step back and look at it, and realize that Microsoft -- or any one software vendor for that matter, and I'm not 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 to seem more and more bizarre how defensive many professional software developers are about Microsoft relative to open source source. How bitterly they complain about open source, feeling that every win for Linux or Apache of Firefox threatens their own future.
None of this is to say that efficiency isn't important -- it's critically important: When I buy a loaf of bread, or shop at a grocery store, or buy a car, it's to my benefit for those organizations to do everything they can to minimize costs, even if that means leveraging systems that make some of their workforce unnecessary. So if Microsoft can throw together a cost effective Biztalk Infopath Sharepoint Portal.NET Server 2007 that eliminates the need for a signficiant percentage of custom development across the land, then that benefits everyone (well...apart from those directly affected -- the people directly losing 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 a personal perspective the argument is not, and has never been, free software -or- commercial software. In fact many commercial software ventures can be helped by the cost savings of free software (presuming that there aren't license conflicts). Your solution looks a lot more palatable when it leverages a stack of free, well-known software, versus requiring a complex mix of server systems and expensive third-party software (we once considered a solution that would have sold for less than $500, yet would have necessitated about $4000 of Microsoft software). Your IT team looks a lot more cost effective when the shop isn't spending millions of dollars a year maintaining various Software Assurance plans, spending tens of thousands on various marginally useful software products per developer head.
It's hardly surprizing that many of the "Web 2.0" success stories started out on, and then scaled up with, open source platforms: Their beginnings weren't hobbled by software fees that exceeded the yearly take of the founders, and they could scale out cost effectively given they didn't require endless CPU licenses, client access licenses, and component fees.
From a personal perspective, I still build solutions largely for the Windows platform, often using integrated technologies such as .NET, ActiveDirectory, and IIS, while leveraging servers such as SQL Server and Biztalk. Yet I do so from a very pragmatic, looking-out-for-#1 perspective -- If I could reasonably justify switching to a free platform, I would. I owe no duty to Microsoft to keep their revenue stream padded.
Recently I had the need to receive some PGP encrypted files on a server, which necessitated the ability to decrypt them from a script. Seemed pretty straightforward, especially given that I was doing something very similar with PGP freeware over a decade ago.
"Uh oh," I though. "here comes the ubiquitous server tax." (the server tax is the fact that commercial software, no matter how trivial, have a propensity to bizarrely cost much if it runs on a "server"). I headed over to PGP and took a look at the command line version.
This is, in essence, just a slightly updated version of the freeware PGP circa 1995, so I was a little surprized by the price (not to mention the nonsensical sales criteria -- you can buy send only, received only, or the super-deluxe send and receive. You can also choose to use only 1 key, or many keys. All ridiculous separations that just lead to 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 such costs get buried under thousands of similar purchases, but these sorts of licenses -- not to mention the administration and hassle 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 immediately fit the need perfectly. The code is modern, and it is fully compatible with OpenPGP implementations. I can use 1, 10, or 100 keys with no additional costs. I can run 1 instance or 100 instances if I want. I can send and receive. I never have to hassle with licensing issues, beyond of course ensuring that code changes (given that I legally and immediately get the source code) that are distributed conform with GPL requirements.
The total implementation cost, especially after considering purchasing and licensing issues (e.g. none), was dramatically less than the commerical offering, offering every bit of functionality we needed (and then some), leaving that money in the pot for other needs. We have the added comfort of being about to plan massive scale-outs with minimal additional cost, increasing the project's versatility and flexibility.
Win/win.