"Art vs. Design" and Code

Maybe its because I consider myself an artist, a coder, and a designer. Maybe its because I worked as a commercial programmer in an ad agency surrounded by talented designers. And maybe its because I served out my studio art minor surrounded by talented artists. Maybe its because I wrote free code in my spare time, but this feature Oskar Pearson struck a chord in me. It talks about Art vs. Design, and Commercial Code vs. Free Code. Something to think about.

The following feature was written by Slashdot Reader Oskar Pearson

This text is inspired by the title of Knuth's famous series: "The Art of Computer Programming".

I have done very little programming. I have, though, been involved in the Linux movement for about 4 years.

I am really playing devil's advocate here. At the same time I am presenting some of the problems with OSS (as I see it). I don't have time to read each and every OSS paper written, so many of my ideas have been probably been addressed.

This started out as an idea on a lazy afternoon near the pool (yes, it's SUMMER in the Southern hemisphere!) I haven't done any research as to the original author(s) of nc, Eric's papers (I haven't read the C&B paper, for example).

Anyway: enough with the disclaimers. Forward!

Commercial art is different to true art. True art is an expression of the artist's soul. Commercial art is aimed at customers: getting them to buy something.

A graphic-design house is not founded to produce true works of art. Sure, there is almost always a spark of genius at the core: if there wasn't, nobody would buy their products ("they can't draw - I don't know how they can call themselves graphic designers").

Graphic design companies will thus attempt to gain a balance: keep the artists happy, but make money too. You do not expect true art from an advertising/design company. The true art is done by their staff after hours, though staff may harness this creative energy and put it into one of their projects.

The same applies to software companies: doing something because you have to will never allow you to harness your creative energies (and believe me, programming requires creativity, as many of you know). Creativity doesn't only apply to lines, colours and sounds: to come up with a truly elegant solution to a problem almost always requires lateral thinking.

So, what does this have to do with free software? Just as an artist does their best work (or at least their most creative work) away from work, programmers do their best work in their free time.

The program may not be rigorously tested (there is no time), it may not be what the client wants, it may not obey any list of standard rules (since when do you regularly use gotos in C code?), but it's creative, it's elegant. It's true art.

The Linux Kernel is a bit like a huge mural: people notice flaws, patch them up (pun intended), other people correct these in turn. Occasionally a master painter will re-do a particularly flawed section. The cool thing about this is other people's changes can be reverted easily, so a punk with a bottle of spray paint cannot ruin years of work.

Like the analogy?

I thus submit the following ideas for consideration:

1. Commercial code will never be really elegant. If it is, it's because the core programmer(s) liked the idea, and treated the project as a work of art (just off the top of my head: consider the 'nc' program for DOS; I believe it was developed by Norton staff after hours... I am quite likely wrong, though: apologies if my facts are messed up).

   The next version will be significantly more inhibited (once the core developers get bored or frustrated).

   It's a bit like a re-draft of an artist's first sketch: remove the way-out ideas, clean it up, make it more conventional. Make it fit for general consumption.

   If it's commercially developed, it's not the software that we love.

2. Free software will never be really user friendly: it will never be fit for general consumption. Why? Because the focus isn't on making users happy: it's on making something that works efficiently, or that has elegant code, or is simply damn useful (perl).

   A coder hired by someone like RedHat to make a nice front end will fit into section 1 unless they are REALLY into their project.

   Quite often there is a conflict between elegant code and pretty output. The fancy boot-up graphics that you see in Windows don't really belong there: it does make Windows seem more friendly though (what's more relaxing than looking at clouds). To someone like Linus, putting the code into the boot loader to do that kind of stuff irks his sense of code aesthetics.

   If code is user friendly it's because it's similar to some commercial app... consider KDE and StarOffice.

   OSS will never be a viable alternative to windows... having users spend lots of time trying to learn a program is costly, more expensive than windows. IT people may use OSS on their core machines, but users will never have it on their desktop: if they do, it's because someone like Corel figured out that there is a demand.

3. Artists feed on each other. In some ways it is mutual respect, in others it is competition. There will always be infighting in the open-source community. Just as some people's minds are wired up to enjoy 'classic' art, and other's are wired for impressionism, there will never be resolution of the Emacs vs vi argument, nor the Linux vs FreeBSD argument.

   On the other hand, perhaps more and more will see the beauty of the other's mural: but I cannot see one mural anywhere in the future.

4. There are a limited number of artists. If the open-source idea takes off, and thousands of companies release their code as source, who is going to hack at all of it? Not Linus, not Alan. (Sorry FreeBeasties: I don't keep track of your gurus!)

   I believe that Netscape is already falling foul of this: there are a lot less C++ coders than C coders. I know a bit of C, but since I have no experience of OO programming I can't really hack around the Netscape source.

   In short: the overall number of eyes to discover bugs is actually quite small. Unless there is company involvement (like the support IBM is giving to the Apache people) then the movement will fail. I have already asked my company if they are willing to donate to OSS groups like li.org: they said no. On the other hand they are willing to buy hundreds of copies of Microsoft programs (because it's the LAW!)

I think that one of the only ways forward here is to create some sort of communal 'D' (as opposed to 'R&D') department, where people literally hack whatever they want to... I believe that Red Hat have been doing this to some extent already, but I believe that it will work best if large groups of people finance other large groups of people. Finding sources of income here is going to be the problem