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.

Re:The golden rule, as always..

[grennis]

Sorry, but that is not the golden rule.

The golden rule is, "he who has the gold makes the rules".

Draw your own conclusions.

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:Modularity and Interfaces

[Anonymous Coward]

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.

Thats why you design the module interfaces well before you start. If you really really must change a struct though, try these guidelines:

o Always pass a pointer to the struct, not the struct itself. If you need to, memcpy() the data at the other end.
o Always add new members at the end of the struct. The locations and sizes of existing members should not change.
o Never, ever, delete a member.
o Build in redundency and allocate extra space for future members, E.g. add a char[128]; at the end of the struct. As you add new members they can eat into that extra space and you can decrease the amount of "buffer" space used.
o If you're using C++ classes, don't mess with the vtable. Don't insert new virtual members, but you can add new non-virtuals at the end of the class.
o Plan ahead and add, say, ten virtual methods that are unused at the end of the class. As you add new virtual methods they can use these vtable entries.

Re:The golden rule, as always..

[Anonymous Coward]

First of all, while there are some good examples of what you say, the fact is that most Open Source-GPL-etc. software sucks and never leaves beta. People can happy at the beginning and drop out as it becomes work to finish it and stop as soon as something works enough to be somewhat usual. Look at this statement, "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." These is because most programmers (and I have met a few in my years) are whinny children without a speck of professionalism and have no idea of the worth of elegance and polish. The dominance of C for many years is America was because it is a dirty little language that allow you to do "anything you want". C++ is a vain attempt to hang a bag on C and tame but if anyone actually read the code, most of it is actually ratty ole C code in a ++ wrapper.
Programming has become an industry of buzzwords and throwaway crap. No one builds on what has come before. No one really pays much attention to good design.

This is one sad state of affairs.

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.

AI Army of One

[Mentifex]

Structure? We don't need no steenking structure.

As the war-criminal and oil-stealing U.S. Army alludes in its recruitment slogan, an "Army of One" is all you need as the vanguard of an Open Source(-Forge) project to create artificial intelligence and bring about the Technological Singularity.

Anything beyond an AI Army of One will be unable to come up with a sufficiently complex Concept-Fiber Theory of Mind to start coding True AI or Good Old Fashioned AI (GOFAI) in JavaScript for teaching AI and in Forth for robots.

A minor problem with the sole-source, lone-inventor Organizational Model for Open Source is that funding is almost impossible to obtain, unless you get your project listed in the Free Software Donation Directory or you write a book about your Open Source software. Even then, the sheeple will hound you as a crackpot, a 'Net-loon or a crank, with the result that even here on SlashDot the vicious malcontents will take up the cry and none of the world-famous Slashdot book reviewers will dare to write a reasonable, mind-opening review of your book, with the result that you will fall off the edge of the Open Source world into oblivion, but it won't matter what has happened to your Army of One, because your Open Source software will have advanced the State of the Art.

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.