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.
Fair enough. (Score:2)
Re:Well, (Score:2)
Re:Well, (Score:2)
Re:Well, (Score:1)
Question (Score:3, Interesting)
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 garg
Re:Well, (Score:2, Insightful)
In the corporate world, a projec
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=178 905&cid=14833101 [slashdot.org]
O. Wyss
Re:Most important one: (Score:1)
Re:That developers like... (Score:1, Flamebait)
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 frustratin
Re:That developers like... (Score:1)
It might have something to do with Richard Stallman. Or the prevalent attitude that IP laws are wrong, that information wants to be free, that closed source software is morally wrong, that charging money for music is a crime against humanity, that downloading music is a inalienable right.
The learn there is no spoon. (Score:1)
Re:The pot calling the kettle black (Score:2)
balance works everywhere (Score:1)
OT trollfeed (Score:2)
If you choose to spend a lot of money on welfare (and other socially beneficial activities) you might end up with a small percentage of people dependent on it all the time and a large majority that needs it once or twice and then bounces back into prosperity.
If you choose to spend all that money on military and waging wa
Re:There are many things OSS projects can learn... (Score:1)
Re:There are many things OSS projects can learn... (Score:2)
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.
Re:Ridiculous! (Score:2)
This happens in most technical industries, it doesn't matter if the individuals are programmers or engineers. It's a very real problem. Moving into management is the only way to move up the pay scale in many companies, so top technical people are moved into management positions regardless of their people/management skills.
Re:Ridiculous! (Score:2)
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.
Not sure if it's what you mean, but this sounds a lot like The Peter Principle.
Re:peter principle , corporate neglect &neglig (Score:2)
IMO, "The Peter Principle" shows a failure of management. Anybody, promoted into a new position, requires some guidance, and mentoring. Failure to provide such is negligence, it's bad for morale, and bad for the bottom line.
It's an interesting read,
Re:Ridiculous! (Score:1)
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.
Having being in several software development companies, I can tell that the main reason for that is that you are dealing with a sort sighted manager/organization that does not understand that these things, while spending money during the development, actually save a lot late
The Peter principle (Score:1)
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.
The term is "the Peter principle". It states that every worker shall rise to his or her l
Re:Ridiculous! (Score:2)
Agreed.
One advantage that F/OSS volunteer projects do have over paid developer projects is that when "development process" starts down the waterfall of endless meetings and lack of productivity, the volunteer coder can more easily walk away,
Re:Ridiculous! (Score:1)
As a developer and consultant who has seen the inside of dozens of corporate projects in 15 years of development, I can promise you that this is not nonsense at all.
The typical life-cycle: Commercial pressure and scheduling optimism leads to too-short schedules, but internal politics prevent feature cuts. The difference is made up in sustainability: code qual
Re:Ridiculous! (Score:2)
Rising to one's level of incompetence
Re: Rising to one's level of incompetence (Score:1)
Another important variety of this is the septi tank theory of organisation: According to this, "the biggest lumps float to the top"...
own particular level of incompetence (Score:1)
It's called the "Peter Principle [wikipedia.org]": Each person rises to their particular level of incompetence.
Re:Ridiculous! (Score:2)
In corparate world projects fail on user side, while in FOSS world projects fail on developer side letting users go free :) Let me explain what I mean. Assume that some company and OS community work on the same big project, that is in high demand.
In FOSS world, if you design software badly, no one will be able to figure out how it works and extend it. If they even
One big difference (Score:1)
That's it right there. Everything revolves around staying within budget, and sometimes, the budget (and usually the deadline) is dependent upon the ROI that the project has to make. F/OSS doesn't have to worry about that.
Re:One big difference (Score:2)
Project Management Is Project Management (Score:1)
There is more to running a successful software project than cutting code. There's making sure the product meets the user needs, training and budgets (cause programmers with lives outside of work like to get paid).
Tell the truth all the time
Trust the team
Review everything, test everything
All developers are created equal
The fastest way through the project is to do it right
That's
Re:Project Management Is Project Management (Score:1)
I'm sorry, but you have never visited my office. If I have to explain that regex is more powerful than home grown searching a string via == operators - I'm gonna go insane. Oh, and what about a 3 year programmer that can't tell me how to inherit an object in
There is no way that you could possibly tell me that bull hocky with a straight face!
Re:Project Management Is Project Management (Score:1)
Trust the team trust is a good thing
Review everything, test everything don't trust blindly thought! (and that is not to blast the other, review, critic, challenge, that is what get someone to move higher, evoluate) -- I hate it when people are afraid to review, or change something because it is already done. It is not a valid argument IMHO and it often cost more to act this way.
All developers are created equal well as anything in life, created I
What the Commercial World needs to Learn (Score:2)
Great article (Score:1)
I also find it amusing that the site says its sponsorted by Mircosoft, who must be the single biggest perpetraitor in cutting corners when it comes to writing software. TFA says that p
Re:Great article (Score:1, Informative)
Also, software is not a commod
Re:Great article (Score:2, Informative)
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 n
Re:Great article (Score:1)
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.
However many eyeballs see it, it's generally a lot more than corporate projects. A lot of corporate shops partition the work so only one person really works with a particular chunk of code. Even in more team-oriented places, you rarely get the kind of review that is pretty much required through open s
Re:Great article (Score:1)
In the corporate world, the code will be looked at only by the next unlucky stiff who's been assigned to "enhance the product" and he'll most likely have no contact with the original coder, so he'll code the enhancements his way and the code will start to look like some of the French
Lessons Learned: (Score:2)
2. Success is a fluke.
3. If you do succeed, document it thoroughly after the fact, to make it look like you had a plan all along.
Re:Lessons Learned: (Score:2)
4. If at first you don't succeed, destroy all evidence that you tried.
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.
One Work: Community (Score:1)
If a company wants to take something away it is that many people (when they contribute) can help to make the solution better.
Here is an idea. Create a group of people who are trusted but not necessarly part of the company. Allow them t
Re:One Work: Community (Score:1)
Of course if people is no assured any deal, it will be easier to get in budget. But, if they have those damn labour rights or opportunities to work elsewhere, do not be surprised if you are finished with some lawsuits and/or no staff/community at all.
A second version of your idea is called "freelance".
More specifically... (Score:1)
What OSS can learn from Corporate Projects (Score:2)
(It's funny. Laugh.)
When is the meeting? (Score:2)
Group of eight people, all trying to get the other seven fired while talking over each other in meeting after meeting.
I'll pass.
Re:It's not the software it's the system... (Score:1)
Re:It's not the software it's the system... (Score:2)
Corporate and OSS are compatible (Score:1)
One of the reasons why we are extremely efficient:
We let our developers work from home. We use Skype and VNC for pair programming.
Lots of bad information (Score:1)
* All developers are created equal
Wrong, wrong wrong. A kid fresh out of college IS NOT equal to somebody who has been working for 20 years. NOT EQUAL. I'm sorry if that hurts somebody's feelings, but that's life. To assume that "all developers are created equal" is completely and utterly wrong. I don't know how better to explain it; this is kind of a common sense thing.
* The fastest way through
Re:Lots of bad information (Score:1)
But as for doing a job right, I DON'T think they meant every project should be done with framework X, service-oriented,
Re:Lots of bad information (Score:1)
Hopefully you'll never have to support the DB interface. Hopefully you won't go on vacation for three weeks and forget how it works. If it's not documented, then it's not done.
Accurate documentation does not take long to write. Lack of accurate documentation is a sign of fuzzy thinking. Fuzzy thinking is often an indicator of poorly thought out code (design, business requirements, etc.).
Good documentation takes a while to write. Good documentation is appropriate for non-core audiences and long-l
Re:Lots of bad information (Score:1)
Your second point is penny wise and pound foolish. If that kid is writing something that you are going to use for a few weeks and then discard, then he should just hack stuff together as quick as possible. Otherwise your approach builds a house of cards. 'Slapping' together code is a bad idea. Sorry if that hurts your feelings, but it has been proven for years. Please read some books on code lifecycle and long terms costs of supporting code and cos
Re:Lots of bad information (Score:1)
This is a common fallacy that equates years of experience with intelligence. While it is true that years of experience can help a person become better at their professio
Re:Lots of bad information (Score:3, Insightful)
Let me tell you what
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 pro
The GIMP? (Score:2)
LetterRip
Stellman (Score:2)
Playing devils advocate (Score:2)
One thing open source projects do not have is deadlines set by market droids. These projects tend to be driven mainly by software engineers who take pride in their work and they do not have to answer to upper management.
Nobody gets fired when an opens source project is late, and to that end, must open source projects have not been promised unrealistically to waiting customers.
Market and Sales droids generate upstream revenue for the company. A good open source project generates downstream revenues for the
Backwards (Score:2)
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:The fastest way through a project is the right (Score:2)
I agree (Score:1)
An interesting read, thanks for sharing... (Score:2)
The one very most important thing to add is this:
while(ossDocumentation != caredfor){
anOSSProject.doGreatDocumentation();
}
Seriously - I have a HUGE amount of respect and owe a great debt to many, many OSS projects (thanks, folks!), but the documentation created by most corpora
The primary difference between OSS and corps... (Score:1)
In OSS, money is not necessarily the primary motivation for development. Even the article skims the surface to this point a litte bit.
Paul Graham wrote an essay on this too (Score:1)
The focus is different though.
My company does these things (Score:2)
I do concur with the lack of good code documentation. Good documentation should allow someone who has never seen the code before to come along and understand what the code is doing.
My observations after 12 years in the industry. (Score:1)
The success of open source projects certainly has a lot to do with their committment to tools, process and communicat
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.
A very trashy and biased story (Score:1, Interesting)
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 i
Its not just OSS (Score:1)
Oh, I know of one thing they can learn from OSS (Score:2, Interesting)
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. ;-)
People "vote with their feet." (Score:3, Interesting)
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.