So What? I Don’t Hack!
Open Source advocates have this unnerving habit of emphasizing the freedom that source code access is supposed to bring its users. At the same time, glaring usability issues are waved away with a “go fix it yourself” attitude. So what? I don’t code, and I don’t plan to. So what’s in it for me? Why should I put up with a Do-It-Yourself work environment with all its lack of polish and disputable user experience?
Openness and Closedness
If you’ve never looked at code, having access to sources is indeed a very abstract freedom which at first glance doesn’t seem to buy you all that much. But let’s move away from programming for a second and take a look at everyday cases where lack of openness is a very palpable pain in the backside even for “just users,” or, to use the economic term, “consumers.”
Ever bought a (legal) DVD abroad that you cannot play at home due to an interesting feature called a “region code”? Ever found your iTunes song doesn’t play on your cell phone, because you cannot convert it to a suitable format even though you obtained the rights to use it?
No need to evangelize about this. The point is: you are trying to combine things in a way you find useful. You run into a brick wall due to lack of openness. Here, this goes as far as treating you as a potential violator of copyright, even though you are perfectly willing to (and in fact already did) pay a fair price for the use of a product. This allegation of criminal intent gives rise to technical countermeasures which are rendering the product effectively unusable for you.
Ok, ok. I still don’t program, I just want to use the stuff, so what do I care about open source code?
Programming and “Just Using”
Programming happens on so many levels. Ultimately, programming is about getting a machine to do exactly what you want. It’s secondary whether you achieve that by typing a time-of-day into your VTR, by running a cinch cable between your tape recorder and your radio receiver, by pointing your mouse somewhere, or by diving into the ones and noughts of machine code. In this sense, there is no difference between “just using” and programming.
Take an apparently simple task like word processing: creating a 10-page term paper with consistent formatting, decent table of contents and a good reference section requires you to think in abstractions. You do not mark stuff as “Arial, 12pt, semi-bold,” but as a “level one sub-heading.” You decide what it is, and later, you specify what it’s supposed to look like. That, my friend, is dangerously close to programming already. Add an innocent “level two sub-heading,” and you are up to your neck in object-oriented programming, with hierarchical categories and inheritance of common traits!
So I’m a programmer by your weird definition. Now get this: I never needed open source code!
Higher-Level Building Blocks
Even if you don’t intend to look at source code, you will see that open source isn’t just about code, but also about design. Building on the good old UNIX tradition, many programs are quite simplistic things written according to the “do one thing and do it well” paradigm. On the downside, this often makes for a more ragged user experience than all-in-one applications. On the upside, it allows you to combine your tools in creative ways the toolmaker did not anticipate.
A few days ago I felt the urge to impress a customer with the number of tempo markers I had to count out and set manually in a post-production session, to allow for edits in a 1’45” accelerando passage that had been recorded without a click. I looked into my Ardour session file and saw that each tempo marker looks like this: <Tempo … />. [Quick exercise for the reader: look into the session file of a commercial digital audio workstation with a text editor and tell me what you see. Oh, random binary garbage? How sad. Storing data as human-readable text is another aspect of openness.]
Now all I needed to do was open that file, pick out all the lines containing “Tempo,” and count them. But it had to be fast and simple, because I was on the phone talking to that customer. So I typed the following into my command line interface:
cat session.ardour | grep “Tempo” | wc -l
You can see three programs in use here: cat reads a file, in this case it’s my Ardour session. The pipe symbol “ | ” tells my command line processor not to print the output of “cat” to the screen, as it normally would, but to feed it to the next program in the pipeline. grep searches through anything you throw at it and outputs all lines that match the expression you gave it. wc is a simple word counting utility, and the “ -l ” option tells it to count lines instead of words. The output was as elegant as the command:
67
The answer was available to me in just a few seconds. The customer was duly impressed, and extended the deadline. Phew.
This is called “scripting,” which means using higher-level building blocks that are strung together as needed. UNIX has been all about scripting for ages. OSX offers it, and lately even Windows has jumped on the bandwagon, with interesting possibilites to tie into mouse actions and nice graphical user interfaces.
It’s not called programming, because, well, users don’t know how to program, do they? :-D
Now you could say: why doesn’t Ardour offer nice “session statistics” to save the hassle? Well, it could. The point is: nobody had thought of this demand before. And the combination of “cat | grep | wc” can also be used to count the number of times the string “kiss” appears in your lover’s emails, or the number of expletives in the Linux kernel sources. [Another exercise for the reader: grep -r “fuck” /usr/src/linux | wc -l ].
Because nobody had to anticipate what you might want to do, you can do pretty much anything.
The handles of a craftsman’s tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for the user’s hand.
That which is overdesigned, too highly specific, anticipates outcome;
the anticipation of outcome guarantees, if not failure, the absence of grace.
— William Gibson, All Tomorrow’s Parties
Admittedly, that’s kinda neat, but spare me the philosophy. And I note with satisfaction that there is still no need to look at actual program code.
You May Be Digging Into Code Before You Know It
I don’t know the C++ programming language. Not at all.
There is this nice digital audio workstation which for some reason doesn’t want to import my Ambisonic soundfiles. But since I know it uses a free soundfile helper library that claims support for the .amb format I use, why doesn’t it let me select and import them?
I browse the code. Behold: the program has a list of file suffixes it thinks it knows. Whatever isn’t in there, it ignores, apparently. This bear of very little brain happily adds “.amb” to the list and rebuilds the software. Magic: now it imports my .amb files. Took me all of five minutes to fix, and to upload a patch so that others can profit from this little improvement. I still don’t know C++.
Making good use of source code means you don’t have to be a proficient programmer to do useful things. Often, you can fix trivial things by just looking at the immediate context, without any understanding of how the whole program fits together. If you want to create something new, you can just borrow all the hard stuff, and then just add those minor modifications that make all the difference to your workflow. Ages ago, I talked plugin author Steve Harris (of Jamin and swh plugins fame) into writing an M/S stereo matrix for me, as a LADSPA plugin. I like the way you can control the source width with M/S, and so I thought, why not use an inverse matrix to convert a plain stereo signal into M/S, modify the M:S ratio, then convert it back, to get width control for arbitrary (coincident) stereo signals? I copied most of Steve’s plugin code, and changed only the guts, which boiled down to some very trivial sums and differences, a gain slider for the S signal, and some more sums and differences. At that time I didn’t even know how to compile a piece of software from scratch — but since I lifted the entire framework, I could just follow the original project’s documentation to build my own stuff.
With open source code, it’s get something done first, learn to program later, while you go.
And if you take the trouble of feeding your improvements back into the original project (what we call “upstream”), you will earn the respect of the developers (usually people who really know what they are doing), which does wonders for the response time to any future questions or issues you might have. Very likely you’ll get some free and very useful programming tuition en route.
And the plural of anecdote is…?
Look, I don’t say you have to hack. It’s just good to know that you can :-)
Social top