Open Source is not an option

Up until now, I always considered open source and closed source software as two competing licensing (and business) models, which both had their pros and cons. This week, I've experienced a couple of things that changed my mind. Right now, I'm convinced that open source is the only sane way to go.

There's a couple of reasons for that.

You gotta learn the ropes

First of all, no-one is born a genius programmer/system engineer/whatever. You have to learn the ropes somewhere, and you always learn by example. Examples that are fabricated as such, instead of having proven their worth in the real world, are mostly worthless and actually demonstrate what not to do.

In college, no-one cares about the software you write. You get an assignment, write some software to solve it, get a grade, and flush it down the drain. Never do you get asked to fix that string replacement program to not crash when customers pipe a 100MB email through it. Never do you have to patch stuff someone else wrote ages ago. So, college assignments are a pretty lame way to learn things.

Open Source Software gives you a far better chance at learning. For one, it is a source of motivation: If something doesn't do what you want it to, not only do you have the possibility of making it so it does, you are actually encouraged to. Open Source project leads love receiving patches. Granted, they might ask you to send them in a specific way or use a certain software to make their life easier, which may suck at first — but once you get used to their way of doing things, chances are you'll see its benefits and find that they made you a better coder.

You can't do it all on your own

Real-world programs are fucking huge and do lots of crazy stuff. People want new features all the time, and they want you to get them right, including all the edge cases and funny things they didn't think of. If you're gonna start worrying about database abstractions, logins and HTML templates before even getting to the actual problem, you're wasting everyone's time. That's not what the customer is paying you for.

Instead, find a good set of tools that allow you to dive right into problem solving and takes care of the rest for you. So instead of writing yet another database abstraction layer (as I, too, have done), find one that works. That'll take you less time and give you a better solution than you ever dreamt of writing, which in turn means you're becoming a much more powerful programmer.

You need to know how stuff works

A nice excuse for not using a library is that "I have to know what the code is doing". Although not using libraries is about the dumbest thing you can do, that point is actually true.

Still, it doesn't mean that you don't want to use libraries. It means that you want to use open-sourced ones, because if you get to the point where you have to know something that's not in the documentation — and you definitely will get to that point — you can just read the source. No piece of documentation is more accurate.

Reading code can be downright entertaining

The other day, I tried to get Python's xmlrpclib to connect to a unix socket. After having tried the obvious thing (and failed) for a while, I resorted to reading the source code for supervisord to find out how those guys did it, and stumbled upon this goodie:

return xmlrpclib.ServerProxy(
    # dumbass ServerProxy won't allow us to pass in a non-HTTP url,
    # so we fake the url we pass into it and always use the transport's
    # 'serverurl' to figure out what to attach to
    transport = xmlrpc.SupervisorTransport(self.username,

Not only did I learn a thing or two about xmlrpclib, I also laughed so hard that one of my colleagues checked to make sure I hadn't stopped breathing. This comment struck me because it's exactly the kind of thing I'd write after having struggled with such a supposedly tiny little thing for a day or two.

Repeating mistakes has gone on for far too long

I've recently seen a talk about the future of programming held by Bret Victor on July 3rd, 1973. Go check it out, it's really noteworthy for one reason:

Bret Victor repeatedly talks about stuff that they tried, that is never gonna scale once the internet turns into something really big, that should be replaced by this other thing they developed recently — and that is still in use today, while we're lucky if the better solution hasn't totally been forgotten about.

For instance, since multicore processors have become common in the last couple years, people are noticing that threads and processes suck balls as a concurrency model, and that the Actor model would work much better. Well, Bret Victor told you so, four decades and a few months ago. Just like he did with a couple other things in that talk, too.

So how come we haven't learned anything since the seventies?

My guess is that people are never taught that writing software from scratch that is supposed to go to production, without first looking around for other software and libraries, is big fat NO-NO. In college, we got told to write software that others could re-use, and that's actually what everybody does — however, noone draws the conclusion that for software to be re-used, you (you!) have to actually re-use software yourself. Otherwise, you'll just repeat other people's mistakes, over and over and over again, and you'll have to be told you're an idiot in a talk held four decades ago. (This is really bothering the hell out of me.)

The world does not need yet another database abstraction framework that supports SQL Injection.

You sell knowledge, not software

Last but not least, think about what it is you're selling to your customers. That's not a hard thing to do, you've been a customer countless times. When have you been happiest?

I for one am the most satisfied when I have a problem and this guy walks in, takes a look, and just fixes it. That's what I love, and it's precisely what I strive to do myself when my customers call me. So, I sell knowledge and experience.

Knowledge and experience that can only be acquired by trying things, making mistakes and failing.

Your customers pay you to ransom themselves from failing, not to fail for them. So, you shouldn't.

Not only does open source software give you tools to make not failing easier. The definition of "not failing" definitely will change over time, and without those tools, you simply won't be able to keep up.

So, open source is not an option — it's the only choice.

<tg1311> Svedrin: ja ein freund des gepflegten rants bin ich durchaus auch :) - meiner wäre genau gegen deinen gestrigen anzusetzen eigentlich .. nur ich muss anerkennen dass deiner - obwohl inhaltlich offensichtlich falsch - sehr gut war und damit einige denkarbeit meinerseits für einen angemessenen konter erfordert hätte