Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Ian Lance Taylor on OSI

Ian Lance Taylor wrote an interesting post on governance of OSI, the Open Source Initiative.

Several years ago I agitated strongly about the lack of any semblance of democracy or transparency in the OSI. I stopped when I realized that the OSI didn't really matter. Since then the OSI has some to matter somewhat more--e.g., sourceforge.net looks to it to ratify licenses. But it still doesn't matter very much. And it is also still completely undemocratic and only slightly more transparent (the increase in transparency is thanks entirely to Russ's efforts to increase communication from the board). These are strange, indeed nearly incomprehensible, characteristics for an organization which claims to represent the community (compare to the FSF, for example, which makes no claim to represent anybody except itself).

The OSI also completely lacks any formal mechanism for correcting errors. Thus the argument that one should judge the results makes no sense; by the time there are results, it is too late.

Personally I think the OSI should drop any claims about representing the community, and instead describe itself as a group of self-selected experts who periodically issue opinions about open source licensing-- i.e., more or less the same as any NGO. I think that would be more honest and more helpful.

posted Fri 26 Aug 2005 in /software/opensource | link

Andrew Morton's keynote

Andrew's talk at lca was interesting, as ever. (I think he reads from a prepared text, which makes it a bit dry, but the text was good.)

One point is that every person who posts a patch to an open source project represents a person who not only has a problem, but cared enough to spend time attempting a fix. Andrew says every patch deserves at least some kind of response, and perhaps to be merged even if it's not the perfect fix. He takes the opposite position to Linus, who says his job is mostly to say no.

Development without a shared CVS server — whether by patches-over-mail or a distributed VCS — runs the risk of being too tough on people who want to put fixes in. I think I've made that mistake in the past.

posted Tue 26 Apr 2005 in /software/opensource | link

Open source as natural monopoly

Andrew Morton raised an interesting idea in his OLS 2004 keynote: systems software tends towards a natural monopoly, for several reasons.

1. Developers don't want to write for platforms that are going to die off. At the moment Linux and Win32 are likely to be around for at least five years; beyond that it's unclear. So people developing software want to bet on the safest choice; this is a self-reinforcing effect. Similarly for people choosing platforms to use.
2. Conversely, once you have invested in learning how to use an OS and its applications, or in hardware to support it, you don't want to switch.
3. Operating systems are defined in CS101 as providing an abstract interface between hardware and applications. Standardizing that layer allows for good competition in both hardware and applications, thereby making the whole stack more appealing.

It's all very well to talk about avoiding lock-in, or standard interfaces, but it's a matter of degree. There is always at least a risk of problems if you try to switch.

Some people like to imagine a world where AmigaDOS, Mac OS, OS/2, Windows, Linux, BSD, etc all happily compete. Andrew points out, and I agree, that such a situation would never be stable.

Given that there will be a monopoly, that monopoly can be either owned by a single company, or it can be a public commons.

posted Wed 25 Aug 2004 in /software/opensource | link

Corporate funding for free software (listen carefully)

The other day I heard someone make these two arguments, one after the other:

1. Red Hat is just mooching off the community's work.

2. Red Hat is wasting their money by giving work away to the community.

(OK, they are not *quite* contradictory, if you assume it is different communities that are respectively contributing and benefiting. But it's awfully close, and this person at least didn't notice it.)

posted Fri 25 Jun 2004 in /software/opensource | link

ACM Queue on Linux

ACM Queue David Ascher has an interesting and balanced case study of a company considering adopting an open-source library. The old chestnut of desktop linux is discussed by Bart Decrem, who is now at OSAF and was previously at Eazel and might have some perspective on it. Meanwhile, John Coates demonstrates that some Americans just don't understand sarcasm.

posted Mon 21 Jun 2004 in /software/opensource | link

The idea of academy

Crooked Timber points to an interesting speech by Robert Hughes about the Royal Academy, and by extension the idea of a professional academy in general. I think in the resurgence of open Unix (Unix as literary tradition) you can see some similar themes.

I believe it's not just desirable but culturally necessary that England should have a great institution through which the opinions of artists about artistic value can be crystallised and seen, there on the wall, unpressured by market politics: and the best existing candidate for such an institution is a revitalised Royal Academy, which always was dedicated to contemporary art.

Part of the Academy's mission was to teach. It still should be. In that regard, the Academy has to be exemplary: not a kindergarten, but a place that upholds the primacy of difficult and demanding skills that leak from a culture and are lost unless they are incessantly taught to those who want to have them. And those people are always in a minority. Necessarily. Exceptions have to be.

I'm not absolutely sure it's necessary, and I don't know who is best to do it. Who speaks about software not just as business or science, but as a culture?

posted Fri 4 Jun 2004 in /software/opensource | link

Ilkka Tuomi on open source development

Ilkka Tuomi has some interesting papers on Linux seen from an organizational or economic point of view.

posted Tue 1 Jun 2004 in /software/opensource | link

Open Source Burnout

(No, not me, at the moment.)

ites writes on slashdot

"Dead" is probably a little overstated, but open source burnout is a real problem for small teams. A product that becomes popular makes great demands on one's time, and when times are hard financially, this quickly turns into a losing situation.

Maybe I'll start a counselling centre for desperate OSS programmers...

Q. I feel inadequate, I have thousands of users asking for features, but I can't deliver _and_ keep my family fed. -- Frantic, IL

Dear Frantic,
Even the best software companies take their time adding features. Don't believe everything you hear about "internet time". Good products of any kind take years to build. Relax. Take your time.

Q. I'm working all my free time on project X, but no-one seems to care. Sure, my users love it, but in job interviews, it's worth nothing. -- Pissed Off, CA

Dear Off (or should I call you Pissed?),
Don't confuse art and business, and for that matter, don't mix them either. OSS is art, you do it because it makes you feel great. Only if you are a truly great artist will people appreciate your work, and you usually have to die first. Get a day job on other merits - perhaps a nice tie - and do your art when the inspiration takes you.

Q. how do I make money from my OSS project? -- Destidude, NY

Dear Destidude,
Money? Did you start it for money? Nah. You started it because you thought "hey, I can do that?" Let me remind you of a basic rules of business: if you want to make money, find a group who have money to spend and make something they want. Who are you selling to? Do they have money? Right. Now stop complaining and change your CV to include "Open Source Migration Consultant".

posted Mon 23 Jun 2003 in /software/opensource | link

noncommercial software and resource horizons

Clay Shirky writes:

Commercial software has its limits, and it runs into them regularly. Any commercial developer has a "resource horizon" - some upper boundary of money or programmer time which limits how much can be done on any given project. Projects which lie over this horizon either can't be accomplished (very few companies could write a new operating system from scratch), or, once started, can't be completed because of their size or scope (as with the Denver Airport baggage handling system).

Open Source software has no such resource horizon - programmers creating Open Source software do it because they're interested in it, not because they're paid to do it. Furthermore, since there's no requirement to keep the source code secret, a much larger of number of programmers can work on any given project, and they don't have to work for the same company, or even live in the same country.

However, the lack of this resource horizon does not mean that Open Source software has no limits, it just means that the limits aren't financial. Commercial companies make software for money, so money is the limiting factor. Open Source developers make software for the love of the thing, so love becomes the limiting factor as well. Unloved software can't be built using Open Source methods.[....]

posted Thu 8 May 2003 in /software/opensource | link

Copyright (C) 1999-2007 Martin Pool.