Prescriptions, Proscriptions, and Prognostications Why do Open Source? by Matthew Wilson April 26, 2008
Summary
A few days ago I was in the office of one of my clients, talking to the dev guys about Pantheios (what else?!), and they were asking why I do open-source. The resulting discussion was quite illuminating, not least to me, so I thought it might be useful to discuss it here and see why other people do it.
Advertisement
Recently, I was talking with the development team at one of my clients about introducing
some open source libraries into their product suite, as we work on refactoring it and
getting it modernised and the code base under control.
As we talked about the various open source libraries available, including several of my
own, the guys asked me why I do open source. I told them a little story of humbling
experience of failure:
"Long ago (in the mid/late 1990s), I created a powerful set of Windows Custom Controls.
In this panoply of fearsome weaponry resided an extended List Box, with multi-columns,
floating editable cells, individually coloured cells, rich clipboard functionality, context
menus, check-box selection, and sophisticated automatic sorting functionality. Quick on its
heels (over the course of a year) came extended Combo Box, List View,
Progress Bar, Status Bar, Size Grip, Edit Bar, Edit Cell,
Button Box, Hex View, Image Button, Hyperlink, and
Context Help controls, all of which were dripping with cool (and easy-to-use) features.
To this day, they contain functionality that is not available in Windows itself.
The initial implementations of the first couple were written in MFC (!), as that was
my main tool for writing C++ at the time. (I learnt C/C++ on various UNIX flavours at Uni,
and then used Borland Turbo C++ in my post-graduates research for three years, but then went
to VC++ 1.5 in my first job. The vestiges of each of these experiences are still in my
practice: I always define the nul-terminator as '\0'; I always
save my files about every 5 seconds with a flash of the keyboard that is visible neither to
the naked eye nor to my consciousness; I use m_ as the prefix to
my member variables)
Use of MFC was quickly dispensed with, as the limitations of being coupled to such a
wretched pile of crap became evident to me. In fact, it's fair to say that my deep
understanding (and abject loathing) of coupling was formed in those days, and it informs
my practice still. Those of you who grok
shims
may give pause to thank the evil that is MFC: being stymied by its coupling, and
wanting to generalise the manipulation of windows between MFC, the "new" ATL,
and my own window façade types led to the first
attribute shim,
get_HWND(), which now resides in the
STLSoft
libraries.
Anyway, back to the custom controls. I can remember thinking at the time that I would be able
to sell these, along with the SDK, to clients who wanted sophisticated and easy-to-use
windowing components all over the globe, and then be able to retire and ride my bike forever
more. It didn't quite work out like that. I was smart enough (but only after I'd spent
all the effort) to realise the daunting challenge it would be to control installation and
version, handle environmental issues and bug reports, and manage the trade-offs between
protecting intellectual property and hindering users. And then there's the hassles of the
financial side and the daunting nature of the warranties. Long story short is that the
controls were never commercialised. They see action in various bespoke projects for
clients from time to time, as well as in several of my internal / free tools. But all that
effort has never seen a direct payoff. The payoff in learning was immense, however, and I'm
very glad for it.
"
(I've been occasionally asked by clients whether I can make them available, and I
still may do so, though as each year goes by there seems less and less point, given the
increasing use of .NET in the Windows GUI space. And then there's the issue that useful
GUIs are disappearing in favour of browsers and other doodads for which you have to use a
blasted mouse, since efficiency in the user interaction seems to have as little regard in
modern thinking as efficiency in software. Anyhoo ... back on theme)
So, fast forward a decade or so, and now I'm a huge fan and user and creator of open source:
I have several libraries of major/moderate/minor significance, and this year will see another
handful. I spend a lot of time working on them, ostensibly for free, and it's the designs
inside these libraries that generally hold my interest rather more than those in my commercial
activities. What gives?
I'd suggest the following reasons, in no particular order of importance, are why I do it.
Some of these may apply to others (and some may not apply to anyone without my particular
psychological pathologies):
Liberation From Warranty. When you don't have to release a fully-polished version,
you can release something that works well "here" and people who need it "there" will
assist (either in reports or advice or patches) in evolving it in that direction.
Evolution. Even the most foresightful person - and that's not me by a country
mile - cannot imagine all the permutations of their work. (I never dreamed of the
Type Tunnel pattern
when I was working on shims for generalising interfaces: it just emerged from the work.)
When there are thousands of eyes on your work, they make requests for the things that they
need, things that you'd never have conceived.
Many Eyes make Correct Work. When there are thousands of eyes on your work, bugs
get identified very rapidly. There's no commercial substitute for this phenomenon. (Look
at the operating system world ...)
Porting by proxy. When there are thousands of eyes on your work, and some of those
are in the heads of people who need it for a platform it currently does not work for, the
portability naturally arises.
Ego. There's no way to say this that'll make you like me, so I'll just give it
straight: I am a ridiculously competitive person, and it is the best part of the game when
I can invent something that no-one else has ever come up with, and it is better - faster
and usually also more robust, extensible and portable - than any competing library. It's all
very well thinking that you've done such things in your own back garden, but putting things
out into the world, code-included, is likely to test such egotistical musings in a very short
space of time. Most fail, some succeed (e.g. Pantheios).
Liberation (somewhat) from Delivery Schedules. This is something to be careful with,
as it's easy to become known as a provider of vapourware. (I'm known as such in the
D world, since I promised a lot, and have (as yet)
delivered little - though I still plan to when I retire ;-) Nonetheless, it's a lot easier to
miss a proposed deadline when your users aren't paying you, and are probably actively
sympathetic, since they may be in the same boat.
Excused Documentation. My Achilles' heel is documentation, at least for open source
work. When you're not being paid by a client, it's all too easy to work on the next smart
evolution than document the current one. Although this is not a good situation, it's still
something that the open source is moderately forgiving of. (It's not hard to go too far,
though: the STLSoft libraries, while supporting a number
of successful libraries, are themselves still largely unappreciated, and that's in no small
part to do with the fact that the documentation is nothing short of woeful. It's been on my
TODO list for 4+ years, and I'm hoping to get to it this year, but there's no promising ...)
Loss Leader. Open source projects can be used as a base, upon which viable commercial
practice sits. For example, a major financial organisation recently engaged
Synesis Software to write custom a
front-end
&
back-end
to Pantheios to tailor it to their precise needs and to ensure that not a single wasted
instruction gets in the way of their application's speed. (Their name, business, product and
the details of the customisations are under NDA because they don't want their competitors to
know that/how they're using Pantheios; but they're in New York, and they reckon they're
producing log output at a rate faster than any software system previously created. You figure
out what they're up to. <g>) As seems to be the case with many UNIX folks, they have very
high efficiency and robustness requirements and were dissatisfied by the characteristics of
other logging libraries. And they're remarkably pleased by the performance of Pantheios,
commenting that it has "clock-cycle speed"!
Ease of Introduction. This is a terribly prosaic reason, but potentially the most
significant. When I go to a new client, and we need to introduce something into their codebase,
it's simple and straightforward when it's open source. There're no concerns with licensing
(because I use the simplified BSD,
which does not "infect" a commercial code base with the requirement to open up itself, a la
GPL's copyleft),
payment, warranties, library evolution, or anything else. For me, the biggest single change
in how I interact with clients is in terms of my using trusted libraries (my own, and others)
in the client systems. Since I've made much of my work available as open source, my life as a
consultant is much simplified. (And there's the not-insignificant reality of the economics: I
can earn more in a day as a consultant than I would likely have earned in a year from any
given commercialised closed source software component.)
So, I'm a firm open source fan who sees a viable commercial side to it. Most of my coding work is
open source, most of my paid work is consultancy, and each washes the hands of the other. And the
best part is that my (open source) users and my (commercial) clients benefit from both aspects.
What's your take on open source? Why do you do it? What benefits do you glean?
Talk Back!
Have an opinion?
Readers have already posted
4
comments
about this weblog entry. Why not
add yours?
RSS Feed
If you'd like to be notified whenever Matthew Wilson adds a new entry to his weblog, subscribe to his RSS feed.
Digg
del.icio.us
Reddit