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.
"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.
A chap wrote a book called The Mythical Man Month 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.
An Eye for an Eye will make the whole world blind - Gandhi
You have a point, for every successful open source project out there, there are ten poorly implemented, poorly documented or completely vaporous open source projects as well. But the same is true in the corporate world - the only difference is money. In the open source world, when a projects dies because of lack of interest or poor project management, it stands about an equal chance of being resurrected by a completely different group of people, or completely disappering.
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.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
... write an atricle riding on the open source buzz.
.. there are good and bad projects in both the open source arena and the corporate arena. The problem isn't learning from one or the other, it's actually applying the processes and management techniques which are well know, well proved, have been around forever but aren't always employed.
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 is a great place to start. I'll take that over 5 pages or general conjecture from any day.
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.
I'll agree with you, and add to this:
When they say: "The code is better because more eyeballs see it" is also crap, because not that many eyeballs see it, much less understand it.
What really happens is that the few who do delve into the code are more motivated to fix it and to "make it right" than those in the corporate world. Furthermore, the brilliant code will have turned out to have been written by more brilliant coders, and so will be, in that particular instance, better than corporate code.
But let's not delude ourselves. Overall, FOSS code is crap, with 95% of the projects out there being badly architected, badly written, often in an ill-suited language, with poor documentation, etc. These projects, however, die the little death of oblivion, since there aren't enough great coders to go around and do them right.
The key, in my opinion, is the coder. If you have a real wizard who can hunker down and eventually grok the problem, then hunker down some more and design a good solution, then hunker down some more and write some working code, and hunker down some more and publish, publicise, share and handle the spam and flames, then, maybe, you will have a great project in the making. A couple or three more coders, and then traction: the project advances 24/7. Thanks to the coders.
In the corporate world, management is especially reticent to trust the "great coders" and will sap their energy and grokking ability through meetings, unreasonable deadlines, tight budget, and more bureucratic paperwork than the french and british governments combined. Thus, the great coders, the hackers extraordinaires, are either pushed out of corps like a champagne cork popped out on top, or slowly sunk in the morass of mediocrity that ultimately drives them to seek fulfillment in non-work activities (like maybe working on FOSS, or gaming, or god forbid, going to see what those flapping dots are in the big blue room).
"Piter, too, is dead."
From http://www.answers.com/communism :
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.
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.
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".
Linux user since early January 1992.
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.