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.
"We have a business to run."
Exactly?
"Those ideas might work in a perfect world, but we need to concentrate on our code."
This happens in both corporate and open source development. Some wild ideas get adopted, other's don't.
"It would be great to do the project like that, but we just don't have time."
See above.
Yet it is rare to find a corporate environment where the project team has anything approaching the level of planning, documentation, or review found in successful open source projects.
So Requirements Analysis, Feasibility Studies, Quality Assurance, Systems Design Documents, and so forth, are all offspring of the Open Source movement, and Open Source is the only entity which employs this 'level of documentation and planning'? Utter nonsense, folks.
For some reason, as soon as a budget and a deadline are involved, all of the lessons we've learned over the years and applied successfully to open source projects seem to fly out the window.
Which is why all proprietary software is garbage? Reality check?
When a corporate developer tries to bring people together to discuss the design of the software or to make plans for how code is added or maintained, he's met with groans about "yet another meeting."
This is true of any business. Unproductive meetings are a hassle to everyone.
their managers often tell them to be careful "not to spend too much time" on it, implying that any activity other than writing code is somehow "frivolous" or "over-engineering."
Apparantely these authors have never seen the inside of business or safety software.
and the programmers should just stick to writing code
Yes, they should. One of the major problems in software companies is that programmers get promoted to positions of management because they excelled at what they did, but they lack management skills. So you've taken someone out of a position they excel at, and put them into a position they need to learn. I forget the term for this.
However, it's well known that corporate projects routinely fail to produce quality software. or even any results at all!
Comparable to the number of abandoned open-source projects you see not updated since 2004. Corporate or open source, they fail just the same.
Open Source has strong merits, but to suggest that Corporate Software is akin to someone hacking out sphagetti code in their basement is just nonsense. What this article should be discussing is how Open Source has adopted and improved many techniques created and employed by the corporate world.
For he today that sheds his blood with me shall be my brother.
This is the most insightful comment I've seen in this article, and the one that in my experience is the most difficult for people to get.
At work, I often have to struggle against cutting corners, and against knowingly doing things wrong to save a bit of time. To me it is completely clear that these "little problems" add up and cost much more in the long run, but it is quite unintuitive that putting extra days or even weeks into code review or strategic planning now, when a close deadline is due, can and is likely to save that amount or more later. The thought of moving these arbitrary and many times virtual deadlines is inconceivable, and fuels countless bad project decisions.
Hierarchical management is based on a model in which the authority, whether manager or technical expert, isn't questioned and doesn't have to explain to anyone who isn't above them in the hierarchy. Thus, managers or VPs announce and don't explain. Thus managers put programmers in a room and tell them to work; since the manager projects that the programmer is an authority, the manager doesn't expect the programmer to need consultation and may even perceive seeking advice or review as a weakness.
This behavior is learned by hierarchical managers and leaders by the school of experience - those who don't follow and exploit it don't get to be managers, leaders, or VPs in hierarchical organizations.
The organization of open-source projects described in the article is not so much hierarchial as collegial. Groups members are judged by their contributions and interactions with others.
Now, the real question is, how does a for-profit company with a hierearchy of stockholders, board of directors, officers, managers, and employees translate the stockholders' expectations of success and the needs of the market and rising above competition to a success-oriented collegial project organization? Middle managers I have known have characterized their jobs and "providing air cover" - keeping management off the backs of the developers so they can get their jobs done with minimal interference. The problem, though, is that developers need to participate in the entire lifecycle of their products, not just get "protected" from the vagaries of the demands of business and marketing and upper management.
The article does bring attention to a key issue in product development, a longstanding and tough one to crack. It is immensely helpful to be able to show the existance of successful practices to try to knock some sense into hierarchical management.
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.