Slashdot Mirror
What Corporate Projects Should Learn From OSS
Andrew Stellman writes to tell us that an article he co-authored with Jennifer Greene is currently being run at ONLamp. The article takes a look at how the most successful open source projects do a great job of putting important software project management principles in practice, using techniques that can (and should) be adopted by corporate IT project teams.
Would it be fair then to compare open source computing programmers to non-tenured professors?
They both find a field they like, are working their backsides off trying to make a contribution, and trying to get their name out in the field. Both also struggle to get their projects working and many may not end up working in the field or place they'd most like to despite tremendous and often beneficial work that might be underappreciated by others. Finally, both also know that it is more often the slow and gargautan inertia of bureaucracy (and perhaps internal fighting among programmers and managers over credit for the projects?) that stall out and crap out more work than the people in the trenches actually planning, executing, and completing the tasks.
Thoughts?
As long as there is a Second Amendment, there will always be a First Amendment.
This story is so biased it is not funny - or maybe it is just the experience of the authors that is so lacking in corporate software development, I'm not sure which.
In the end, it all depends on who you work for, either in open source projects or commercially. The practice of code walk through and code review is not something that is only the province of open source. Ask any _SOFTWARE ENGINEER_ and they will agree.
Similarly, if you have a manager who is or has been a programmer or software engineer then it is quite likely that they will understand.
So what's the crux of the problem? In the commercial world, it is too common for software projects to be run by managerial staff that don't understand software. Replace those people with experienced software engineers and the problem will vanish. So get your 40 yr old programmer who is now "over the hill" and send him on an MBA course somewhere and have him run your software projects.
But I do know one thing - I don't want anyone involved in the creation of that story ever involved with any software project I work on because that article does a very good job of telling me that none of them have any clues or experience in doing anything other than trying to write a sensationalist article. Enough that I'd call the people who wrote it "reporters" and not "journalists".
Embark on a very promising and exciting project, work actively on it for months with a nice team, and then the project manager ends up getting the flu, one or two team members start getting bored, and the project dies and nobody ever hears about it anymore. Of course, all of the source code and documents are archived there, but the new team actually thinks it makes more sense to start a whole new project altogether.
And I'm not even trolling. ;-)
This article is obviously an ad, but I still take issue with the overly rosy portrait of OSS leaders it paints. The benevolent dictator idea is nice, but it misses the most important point in the comparison between OSS and commercial softare: OSS contributors can make a fork.
A lot of management is about politics, trying to promote your own preferences/ideas while appeasing the other people who have power over you. OSS is rife with this kind of crap, especially since a lot of people put ideological and emotional stake in their projects. The difference is that the leaders of an OSS project have to appease the contributors or they'll have the project taken away from them. Corporate managers can make decisions that their underlings don't like, because they are in control; OSS leaders have to make compromises, even if it's not what they really want for the software.
Both options in OSS can be good or bad -- forks make a more fine-grained set of solutions to the same problem, but they make several similar options that are hard for new users to choose between; compromises can make software appeal to a larger user base, but they can also dilute the vision for the software -- but it is the inherent democracy of OSS that more than anything makes it unique.