Early Perspectives On Open Source
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/ "http://c2.com/cgi/wiki?FreeAsInBeer">free software versus
Flurries of emails rained over our respective groups, as we
fought to evangelize and fortify our positions, building "http://www.flickr.com/search/?q=bunker%20military&w=all">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 "http://en.wikipedia.org/wiki/Capitalism">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
The Face Of Open Source Evangelism
My opponent, in contrast, was a GPL-embracing, Linux-advocating,
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
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 "http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/xpactiv.mspx">
intellectual protection: Innovation in that realm was no longer
driven by capitalist forces, but instead arose from scratch-an-itch
Everyone would benefit, he advocated, if we all contributed to
the global software pool, and we could all "http://sourceforge.net/">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.
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.
The Benefits of Open Source
Win/win for everyone: Retailers got a customized POS system for
(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.
Seeing the Light…Or At Least Catching A Glimpse
At the time I thought he was nuts, or at least irrationally
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 "http://www.redhat.com/">enterprise-friendly of vendors. I
still think the "http://www.firstmonday.org/issues/issue3_3/raymond/">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.
Free As In Beer
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
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
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 "http://www.gimp.org/">GIMP to "http://jalbum.net/">JAlbum to "http://www.jgoodies.com/freeware/jdiskreport/">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.
Doesn’t This Hurt Developers?
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
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
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
Efficiency Benefits Us All
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.
How This All Came About
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
“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
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
"http://www.gnupg.org/">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.