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 golden rule, as always..

[jkrise]

If it's good, widely accepted, and works well - don't fix it. Open Source, GPL etc. should fit into this category.

Re:The golden rule, as always..

[pe1rxq]

You might wan't to check how many non-opensource programs are actually finished or the amount of crap in it...

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.

I don't think programming has become that... but indeed the industry certainly is.
The industry are managers who don't know shit about programming that are selling programs with a bunch of marketing buzzwords and throwaway crap. The programmers don't have much to do with that (except letting them abuse...)

The reason C is so popular is excactly the reason your argument is moot... Programmers (the real ones not those that think using a computer means using a game console and then move on to 'programming' in visual basic script) use it because they are not impressed with the latest buzzword compliant programming language that promisses to solve every problem.
They use what works, and for a lot of problems C just works.

Jeroen

Fourth big challenge

[aaronlev]

Removing the cobwebs. People almost never remove old stuff. For example: - old projects from sourceforge - old module owners from the mozilla.org list of module owners - old out of date documentation The older a project our the community gets, the more bloated it will get with incorrect information. Try to do some work, and find you wasted a day because of out of date stuff. Projects need a little, eek dare I say, management.

Only one?

[Anonymous Coward]

The article is titled The Organizational Model for Open Source, but is there really only one model? The Linux "benevolent dictator", Perl "pumpking"[1], FreeBSD "board" etc. are all different models (And there are more). Surely all these different models have different dynamics?

[1]: Fnur fnur

Follow the money

[drpickett]

Access to capital comes at a price - Duh - If there are those who invest the funds to create an NP foundation to promote the development of open source they are going to want to influence things like organization and maangement discipline - Think of the larger charitable foundations that are out there - The investors are not interested in a profit, but they are interested in having their dollars drive a portion of the investor's vision - The price in this case may be the need to actually document code, keep it clean, and produce to somewhat of a schedule - The coders may be volunteers, but the price that the coders pay for access to the fountation's resources is a bit of formalism - Sounds like a fair trade to me

Re:Credit where credit is due

[Jellybob]

But it wasn't about the technical details of how open source works, it was about the management of *people*... you know... those things that spit out code for you.

Forgot SCO??

[jkrise]

The biggest challenge comes from those who lose when a particular model succeeds. Proprietary, closed-source, cash-strapped, IP wielding firms who employ (litigious bastards -to quote Slashdot) are bigger challenges.

Not to mention being branded communists, success haters, neo-terrorists, non-conformists, traitors etc.

The fact that Open Source succeeds despite all the above does indeed speak very highly of it's underlying strength of purpose and motivation.

Sounds like Lava Flow...

[fingal]

I don't have my copy of Anti-Patterns with me, but quoting from memory, the Lava Flow anti-pattern states something along the lines of:-

The more legacy code in an application, the greater the chance that the people responsible for the code are no longer involved in the development of new code. This leads to an inability to change the legacy code, mainly based on fear of undocumented effects of the changes. As the amount of "untouchable" legacy code increases, the diffuculty in making new changes increases until the point when the Lava Flow cools sufficiently into an immovable solid mass that becomes basically unmodifiable without major low-level re-writes.

Good managers vs PHB stereotype

[seosamh]

According to the article,

"Much of what is funny about Dilbert cartoons is the disgust that technical workers have for managers who do not have intimate knowledge of the content of their work."

That doesn't match my experience. The best managers, those who can clear the way for/get out of the way of their technical staff, don't earn disgust, but respect, despite not having "intimate knowledge of the content" of the techies' work.

Generalizing to all managers who don't understand the technical content misses the point.

Re:Good managers vs PHB stereotype

[Mostly a lurker]

Generalizing to all managers who don't understand the technical content misses the point

Very true. It has long been my view that the best managers of technical people are those who act as motivators and facilitators. While a strong technical grounding is sometimes an advantage (especially when judging who to assign to a project) limited technical knowledge does not necessarily prevent a manager from doing his job. It is important that a non technical manager knows his limitations, though, and is willing to defer on technical matters to those with superior knowledge.

Re:Harvard Business School?

[goldspider]

"WTF do the people at Harvard Business School really know about open source?"

Probably more than you give them credit for.

I'd also be willing to bet my left nut that they know more about business than you do. I'd say that qualifies them to address the subject.

There's only One True OSS Model

[heironymouscoward]

1. Blood, sweat and tears
2. ???
3. Kudos!!

Why Kudos and not Profit? Easy, and this is the key to OSS: you need money when you trade with strangers. When you trade with people you know, reciprocity is enough. OSS is possible because of community. The community is possible because of cheap communications.