Open Source Organization Models Discussed

blogologue writes "Harvard Business School has an article up discussing The Organizational Model for Open Source. It has some good points, and I think it sums up what many of us know, but haven't quite been able to put into words yet: 'People are intimately aware of the fact that too much structure will disenfranchise the very people who make the most successful open source projects possible.'"

Comments

The ultimate open-source organisation model:

[Anonymous Coward]

Goodwill.

Where is the article going?

[SanGrail]

The article didn't seem that coherent. There were some interesting questions asked, and completely different answers given.

E.g.
"Could you explain why the emergence of nonprofit foundations in the hacker culture appears to be a contradiction in terms?"
Why anyone would think it is a contradiction in terms is possibly an interesting question, and it isn't answered. Yes, Open Source projects often operate on a meritocracy, and those who do the work, often make the decisions - and may become 'board members' etc when it makes sense to set up a non-profit foundation.

Also, how much of a model is a 'non-profit foundation'? As overlayed on an opensource project? It may not actually have that much relevance as to how decisions are made, and the project develops.

Also, could someone explain what Prof. Stark means when she refers to 'community forms'?

Modularity and Interfaces

[MongooseCN]

The model I find that works best is Modularity and Interfaces (I don't think that's the actual model name, I forget). The lead designer focuses on code that can easily be seperated into individual components (modules). These modules then have interfaces defined but little to nothing about their internals are defined. This way these modules can be handed out to people to code and there needs to be very little interaction between coders of different modules.

The problem with this model is that performance will be lower because there is less interaction between the internals of modules. But this day in age, easy maintanence and stability are more important than a few cpu cycles.

One problem that crops up pretty often with this though is struct interfaces (I use a lot of C). When a member is added or deleted or a module owner notices the need for a new member, this can affect lots of other modules owners.

Re:Credit where credit is due

[Surak]

Ummm...did you actually *read* any of those works? They're The Cathedral and the Bazaar and Homesteading the Noosphere are *specifically* about the management/sociological models of open source. The Magic Cauldron deals with the *economics* models of open source. These are the classics that deal with the management, sociology and economics makeup of OSS.

If you haven't read them, by all means do so. All of the concepts you hear about 'scratching the itch' and 'organized chaos' here on Slashdot and on various OSS mailing lists, etc. are discussed in depth and in detail in those books. Despite what you might think of ESR and his politics, his books are *very* insightful.

Re:Fourth big challenge

[eugene ts wong]

Exactly. You have to find someone to replace you as the owner of the project. Someone emailed me to take over my project because the name was exactly the 1 that he wanted. I was fortunate enough to have someone like that come my way.

On an unrelated note, I almost deleted his email requesting the new ownership, because I thought that it was spam.

Dijkstra's Papers

[Hubert Q. Gruntley]

A short while ago, Dijkstra's papers were made available online. Slashdot article here.

A pervasive theme was that managers don't like exceptional people... he decried "the collectivist desire to play down the potential role of the individual." Managers always scorn rugged individualists because they mess up the well ordered meetings.

This may be the reason, and the only reason, why open source is successful: because we've invented a system where brilliant individuals can work together.