Slashdot Mirror
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.'"
If it's good, widely accepted, and works well - don't fix it. Open Source, GPL etc. should fit into this category.
If you keep throwing chairs, one day you'll break windows....
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.
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
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
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.
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.
If you keep throwing chairs, one day you'll break windows....
> Most open source projects have been
> non-profitable so far.
Perhaps not profitable for the project owner... but quite profitable for the users.
The Army reading list
And how many closed source companies make big profits again? Only the big ones do. The small ones are having problems surviving.
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 only Good System is a Sound System
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.
WTF do the people at Harvard Business School really know about open source?
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.
Ceci n'est pas une signature
i don't know about you, but what's the percentage of good managers, such as you describe well, and the rest of the managers in the business world.
:>
i don't think anybody would argue that a good manager's job is to manage staff well: give the amount of support and assistance to permit staffers (and not just developers) to reach objectives.
it's just that they seem in short supply.
ed
Well, let me give you an actual example, not from some major Open Source project but from a non-profit MUD.
Most MUDs tend to work like that. Some players eventually volunteer to help you create stuff. Some rare cases can help with the actual programming part, but most can fill the equally (if not more) important part of writing content for that game.
And for some reason, they tend to attract a lot higher volunteers/users ratio than other projects. Maybe because you have them coming daily to your site anyway. Maybe because it's official that you don't need to be a seasoned C guru (or even know C at all) to donate some help. Dunno why.
But either way, I was one of those who thought "hey, maybe I can help too." You know, give something back to the community and all that.
What I had not counted on, was that in the meantime it had grown beyond the stage of a few volunteers helping with whatever they can or feel like.
It had evolved into a sort of a faceless corporation. As soon as you joined as an unpaid volunteer helper, you got assigned a boss and deadlines. You had to write reports of what you did and what you're doing now.
In fact, worse than a faceless corporation. Those few who got to be the "bosses" didn't even have to worry about keeping you as an employee. Weren't about to start taking suggestions, either.
And then came the paranoia. A select few came to the idea that "hey, other MUDs are stealing our precious code!" (Never mind that those others more likely just copied a few room descriptions, since those weren't even running the same codebase, and porting code would have been more work than it's worth anyway.)
Now it had never been truly an open source project, but there was, well, at least some illusion that you're contributing to some common pool of code, for the common good. Now it turned into an ACL fest, where even to get to the examples directory, you had to negotiate with someone. It was as much fun as negotiating with terrorists. And you had to go through it again for every single directory you wanted to have a look at. There were hundreds of directories.
Didn't take me that long to get to the idea that my day job was, in fact, _more_ fun than that. I quit and never looked back.
So the point isn't as much about haircuts and basements, but that when someone's voluntarily donating work, they're not happy to take the same shit as from their boss at work. People are doing stuff on their free time, and they're doing it only as long as they like it. If you turn it into something which resembles a full time job, only without the pay and medical plan, they'll go do something else instead. Assholes and control freaks don't make good leaders for these projects.
A polar bear is a cartesian bear after a coordinate transform.
Check out Mahony's (the interviewee in the article) dissertation