What Corporate Projects Should Learn From OSS 110
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.
Ridiculous! (Score:4, Insightful)
"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 [wikipedia.org], Feasibility Studies [wikipedia.org], Quality Assurance [wikipedia.org], Systems Design Documents [wikipedia.org], 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.
Meanwhile in the 70s.... (Score:3, Insightful)
A chap wrote a book called The Mythical Man Month [amazon.com] which talked about lots of lessons that IT project managers and others could learn about the successfull delivery of IT systems. Including a very developer focused methodology called "The surgical Team".
Oddly nothing in the article is actually stuff that businesses that do IT well could learn from Open Source, as Open Source has learnt it from people who do IT well. The worst bit is that 30 years on people are still putting forward the bleeding obvious of project management as being "best practice" and most (including this article) don't come close to a book written in the 70s, written by a chap who worked at that ultimate of old school organisations, IBM.
If anyone is working in IT and hasn't read the Mythical Man Month, then you should especially the special edition I linked to, best book in IT ever by a mile.
Good project managers can teach other projects managers lots about running programmes, no matter whether in closed or open source, product or end-user applications. Trouble is too many people go into project management because they don't have the talent elsewhere, that is like having the quarterback as the weakest member of an American Football team.
Re:Well, (Score:2, Insightful)
In the corporate world, a project has the same options, but the kicker is the money already invested in the project. If a poorly managed, but nevertheless profitable, project begins to fall apart, a company is more likely to throw money at it in the form of people or hardware to keep it alive than to just let it die. Even a poorly managed project can be kept alive with a steady influx of cash.
Therefore, truly well managed open source projects should definitely serve as a model for corporate project management. If a project can be kept alive and growing through good management, without the benefit of a cashflow - theoretically, corporate projects could benefit from an application of the same principles.
Step 1 ... (Score:2, Insightful)
Step 2: Get free publicity for consultancy
Step 3: Profit!
It's nothing to do with learning from open source management techniques, it's about employing solid engineering principles. Stating that having good documentation will help a project? Anyone (with a brain) think otherwise?
"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."
This certainly doesn't match my experience of corporate projects, but then I may have just been fortunate.
One might equally say "yet it's rare to find an open source project where the project team has anything approaching the level of planning, documentation, or review found in a successful corporate project".
I don't think it's anything to do with whether a project is open source or not
As someone pointed out, Mythical Man Month [amazon.com] is a great place to start. I'll take that over 5 pages or general conjecture from any day.
The fastest way through a project is the right way (Score:5, Insightful)
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.
Re:That developers like... (Score:3, Insightful)
From http://www.answers.com/communism [answers.com] :
Sounds pretty much like open source to me.
You seem to have a problem with the word 'communism' as if it is some kind of insult. As a libertarian (quite far from communist), I find it frustrating that people take such offence to the word.
Tell me, which current system of government is (was) defined by free speech and transparency?
Firstly, just because current instances of communism have become corrupt in those ways, does not make that inherent to the concept itself.
Secondly, the (troll) parent was not comparing those parts of communism in the analogy. After all, lack of free speech and non-transparency are not part of the concept of communism, only the instantiations of it that have occurred in history.
Thirdly, the wording of the parent was 'communistic', which to me can be used to mean commune-like, as in hippy commune, or as in many people working together without much of a heirarchy of power. Rather than meaning straight-out communism.
Why management has a different viewpoint (Score:3, Insightful)
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.
Money (Score:1, Insightful)
- Linux by OSDL, RedHat, IBM, Novel and lots others
- Firefox by the Mozilla Foundation
- OpenOffice by Sun,
- Gnome by RedHat,
- KDE by Novell
Think!
See also http://developers.slashdot.org/comments.pl?sid=17
O. Wyss
Re:Lots of bad information (Score:3, Insightful)
Let me tell you what I'd rather want for my software project: I want it to be architected by an EE guy with no formal SE training whatsoever but with a metric ton of experience and insight into software (hello Eddy! :-). Yep, he's very intelligent too, but that's besides the point: it allowed him to become the developer he is, but I want him on my project for what he's worth, not for the potential he has to be worth something 5 years from now. I do not want my project architected by a super-bright fresh CS graduate that has no experience whatsoever. Sure, I want that guy on the team as well (if and only if he also is a teamplayer, that is!), but I will never axiomatically consider him "equal" or "better". He'll have to *prove* it first.
I'm a CS guy with 17 years of experience myself, by the way, and I'm the formal project leader. But I know when to recognise developers that are better than me, instead of claming that "I'm created equal, since I am (or at least was) a decent software developer too".