Subject: Re: Developers/Free Software/Open Source
From: Taran Rampersad <>
Date: Sat, 01 Mar 2003 16:56:58 -0800

Robin 'Roblimo' Miller wrote:

> I can easily argue the "Artists who produce poor art usually don't 
> make money" statement with you. :) 

No need to argue :)

> That aside, problems faced by FOSS developers are exactly the same 
> problems artists, writers, and musicians have faced for the past 
> couple of dozen millenia. 

Yes. And I think we can agree that advances in technology have only made 
these problems more glaring.

> There are two basic ways to approach art/writing/music/programming:
> 1 - Scratch my own itch
> 2 - Find a need and fill it

In other words, scratch it yourself -  or - if you scratch my back, I 
scratch yours. :)

> Most writers, artists, musicians, and programmers don't have very good 
> business heads. An example of one who does is a guy I know named 
> Verne, who lives in the L.A. area and is the absolute king of... pipe 
> fitting clip art for plumbing catalogs. Verne is an excellent painter, 
> but pipe fitting line drawings (and some food clips -- he does great 
> lettuce) pay the mortgage, keep his wife's closet full of clothes, put 
> the daughters through college, etc. Now and then Verne gets enough 
> paintings together for a gallery show and he usually sells a few of 
> them. He calls this his "Harley money" because he spends his fine art 
> income on motorcycles. He has four of them -- all Harleys -- but it 
> took him 25 years to buy them. Obviously, when it comes to income, 
> pipe fitting line art is a better bet (for Verne) than impressionist 
> painting.
> Verne found a niche and filled it. He works, at most, 30 hours per 
> week, and a good 10 hours of that is sales, billing, and collection. 
> He used to work a lot harder, but his daughters are grown now so his 
> income needs are reduced. He owns a little income property he hopes 
> will support him in retirement. He is not poor. He is also not 
> terribly ambitious. Verne would really rather ride his Harleys on Rte 
> 1 than draw or paint. He started taking a businesslike attitude toward 
> his work only because he got his girlfriend pregnant and married her. 
> Before that he was not interested in money at all.
> So far, the majority of successful "free software businesses" I see 
> are in the business of solving client problems, and happen to use free 
> software as a tool. Sure, they contribute back to the community, but 
> community contribution isn't their primary motive. Their primary 
> motive is to fill their customers' needs and turn a profit in the 
> process. 

Right, that's how these fit, I agree.

OK - from the 'scratching-the-itch' department, there is one thing I 
think that we're leaving out...

3 - Create an itch and scratch it.  (Or - "Hey, that looks like it 
itches...does it? Are you sure?")

Developers have this one advantage over artists, writers, and musicians. 
They can create their own 'itches'; they can create a need for products. 
Email is a great example of this - a media that many of us use now. GNU 
Linux is also another example - where a new operating system generated a 
need for new applications. Heck, let's not forget the Internet.

This third one is the most interesting, and probably the most 
profitable. Artists are limited to their media - as are programmers - 
but the media itself is not as simple as a canvas or even a piano. The 
computer can do all sorts of things, and we've really - only now - 
scratched it's potential.

> You've heard me mention the idea of the development process itself 
> becoming the  most valuable intellectual property a free software 
> business can have. I did not mean that "the development process" was a 
> product that could be boxed and sold, but that a major key to success 
> in a "fill the customers' needs" business, especially when the needs 
> you are filling have to do with software or network 
> installations/maintenance, is the ability to operate with greater 
> efficiency than competitors.

In this I agree completely - to a point. It's up to each business - or 
developer - to develop a process for creating software and *constantly 
refine* it. Operating with 'greater efficiency' at times and being 
aggressive about process can also be detrimental. The process is always 
a guideline, it is never the rule. The process should not define the 
software - the software should define the process. The process is 
dynamic. I worked at one company where the software process changed 
faster than they could release the changes to the process, which is 
rather amusing in retrospect (the process to release processes needed 

It's not the process itself that is valuable so much as the ability to 
adapt the process. This requires people, and a business that can adapt 
quickly and efficiently. One of the failings of adaptation of the SEI 
CMM is that people ignore the fact that the process must change, and 
though the process must be documented, it does not have to be documented 
traditionally. The other failing of the adaptations of the SEI CMM is 
the whole rating system, where a customer demands that their supplier 
meet a certain SEI rating. This contradicts the CMM itself in practice - 
I have seen first hand what companies will do to *mimic* the process so 
that they can get work instead of actually working on their processes. 
SEPG meetings I attended were focused more on defeating the very process 
that was in use, instead of creating good software.

Businesses that use processes should be as dynamic as their processes 
need to be, probably.

> - to be continued -
> - Robin
I look forward to it. :)

Taran Rampersad