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.
I AM A FISH!
They could learn to set up half-done sourceforge projects that never go anywhere, or fail to provide any indication of support or activity in the past few years. Instead of giving out documentation, they could give out the source and make the users figure out how to use it.
Then I say we throw you back.
As long as there is a Second Amendment, there will always be a First Amendment.
Don't pay your programmers.
I'm sure they'll take that one to heart.
Note to mods: I'm probably being sarcastic.
That people who are too cheap to buy software love communistic schemes to cook up a shoddy imitation? On a related note, is Red Hat trying to look like Windows 95 or Apple 8.0 this week?
An Uncomfortable Truth
Only forks.
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.
One of the major assumptions of modern economics is that people won't do anything unless they're paid. The RIAA, for instance, will insist that we won't be able to listen to music unless the musicians and everyone else in the food chain gets every possible penny from us every time their music is played.
OSS proves that people will create great economic benefit even if they aren't directly paid. It is a very strong counter example to the conservative school of economics that seems to be running the country these days.
It's articles like this that make me hate the ID people even more. I mean how asinine does it get!! Can't they see that ID is so much crap??!!
as long as people are given some basic direction but still can move freely, they feel happy. when there are too many constrains, people get unhappy and perform not so well. this applies to programming, sports, politics and civil rights.. thats why socialist/communist/autocratic states usually go bankrupt soon. balance is the key to success.
...from the big boys also:
:)
1)Cripple the features of your software when your costumer uses a competitor's product. Say, make it look like it's running twice as fast on linux because you are actually making it run half the speed in windows.
2)Enable spy^H^H^Hcostumer feedback features. Your program can easily report important information back to $sys$headquarters, enhancing their user experience, while at the same time hide it's existance to not get in the way of the costumer.
3)
4)Threaten your clients with lawsuits. It's the latest trend. Hell, the source is with you on this one. Just claim everyone is illegally using GPLed code in their products and by using proprietary products people are putting their business at risk.
P.S. 3) Promise features that are not there, and sell them as features in a later release!
"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.
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.
Saturday is April 1. Slashdot will be shut down. Sorry for the inconvenience.
Its foolish to this that conscientious project managers in industry do not do the things that this article does.
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 a good start, how about the rest???
The man in black fled across the desert, and the gunslinger followed (SK)
That all code should be "production quality" code. There's no excuse to have internal tools written like crap, and unmaintainable.
I am unamerican, and proud of it!
I think it's a great article by ONLamp and offers non-developers an insight into what its like to work on a FOSS project. Sure, I've reported many bugs, helped out on community forums and mailing lists - but I've never contributed code in the way highlighted in the article - via peer review with structured rules and processes.
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 peer review is good for the company reputation but bad for personal reputations within a corporate environment. Peoples mistakes get exposed in the board room or to the project manager. The hierarchy in companies is damaging to software development because it lets power override logic and the truth.
If they could take their time and develop using similar strict rules and processes without the fear of losing their jobs, being embaressed/defensive or being shown to be bad coders, we'd be sure to see more quality and solid software from the major players.
At the end of the day though, software is becoming such a commodity these days that it's in a companies best interests to make as many releases as possible, with the shortest time possible until its retired and superseeded.
1. Fail frequently.
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.
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
Open sorce has one major advantage over a closed source product. It is the power of multiple people. In a community setting people give ideas, fix problems, and help troubleshoot. In a closed source project the company simply allows people to help with new ideas and FAQs.
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 to work on createing new ideas based on seeing the frame work. Think of it as a hybrid close/open system, a "Confidential Code" shall we say. These programers can do bounties on bugs, test beta versions or write new functionality for submission and integration into the main program.
This way they can get outside help on the areas they would rather not worry about. Community. When it is there it really helps.
Procrastinating life a way at a rapid rate of speed.
We can learn from them, too. For example, everyone thinks that our project's FAQ is far more professional and business-like now that we've changed it from a "FAQ" to a "Knowledge Base."
(It's funny. Laugh.)
Tired of FB/Google censorship? Visit UNCENSORED!
corporate IT project teams
Group of eight people, all trying to get the other seven fired while talking over each other in meeting after meeting.
I'll pass.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
Many open source projects are forced to use such system because the developers aren't in the same area, or even country, so they need some way to track the project and often choose one of the various software packages, where as many IT projects go without a system because the people feel that they can Wing it and the time required to deploy such system is a waste, by communicating with each other, but with out a set format to track the project and manage it, it often fails.
Being that I work for a Microsoft shop I use Microsoft products, Project, Visual Studio 2005 Team System (a recent change over, that I have been liking), Exchange mailing lists for communcation among the teams when out of the office, and Sharepoint. Open Source developers have their own tools which allow you to do the same.
The assumption that the grandparent advocates communism is as bad as the assumptions you accuse it of making. Anyway, those who run the country these days do indeed seem to be of the opinion that anything that isn't privately owned is bad.
The title is somewhat strange: We are a company and we write open source software. Who says that corporate software can not be open source at the same time?
One of the reasons why we are extremely efficient:
We let our developers work from home. We use Skype and VNC for pair programming.
db4o - open source object database for Java and
This article is so incredibly wrong, I just want to rant about a couple of the worst points:
* 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 the project is to do it right Huh? No it isn't. The fastest is often to slap together something crude that works. It's all about ROI. If I hire a developer to write a quick and dirty DB interface that only I use, and he takes 6 weeks to do it, because he's sharing and holding hands, and documenting, and using source control, etc., then that developer will be fired.
I get the impression that the authors of this article have never held down a paying programming job. The nonsense that they're spouting is so utterly far from reality that it's funny.
I don't respond to AC's.
... 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.
Isn't using the GIMP as an example a poor idea? No disrespect intended but I got the impression that they have had all sorts of issues with missing schedules, difficulties migrating to planned technologies, high overturn of individuals working on key technologies, etc.
LetterRip
I read that as "Andrew Stallman" at first. I thought maybe RMS had a child. Probably a love child from the 60s. Perhaps he had bathed once and gotten lucky. Or maybe all that free love actually worked for him. (I'm kidding. Mostly.)
Software sucks. Open Source sucks less.
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 engineers.
-Nuke the moon
It should be the other way around. It's what can OSS learn from business to into enterprise. I attended PyCon. I was impressed by the way a number of them realized and advocated interacting with normal people and adapting to them rather than beeing geek know-it-alls. And they had social skills. Yes, you can be a geek and have social skills. Oh wait. that's part of the definition of being a geek no social skills. Never mind.
"You'll get nothing, and you'll like it!"
In response to the idea that programmers should just stick to writing code, it was written:
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 level of incompetence.
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 found TFA to be interesting and stimulating. Although I don't agree with all of it, it makes great food for thought. Indeed, corporate IT/Engineering could learn a great deal from the better-cared-for OSS projects - no doubt.
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 corporate IT spanks OSS documentation (note that I said most). I am fortunate enough to work for a great software company that knows the benefits of good care and feeding of both the documentation crew and the documentation - I guess I'm spoiled, in that regard.
A Passionate Independent Musician
Duh! It's the money stupid! The primary motivation of any corporate decision is how fast and how cheap can we produce it. How much effort would it take? At what costs? What's the ROI? What's the risks? Blah. Blah. Blah.
In OSS, money is not necessarily the primary motivation for development. Even the article skims the surface to this point a litte bit.
Coderz 4 Life
http://www.paulgraham.com/opensource.html
The focus is different though.
Obviously I cant really say where or go into big details but the place I work (big global tech firm) already does good software development practices including things like code review (nothing goes into the main development tree for the project unless its been inspected first)
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.
I've worked for 12 years in the computer industry, 8 of which were involved in the gaming sector. The biggest factor, I believe, to project failure has more to do with vision, passion and committment; the lack of proper process, tools and communication are more symptons resulting from the lack of vision, passion and committment rather than incompetence or ignorance of such tools and process.
The success of open source projects certainly has a lot to do with their committment to tools, process and communication. But more importantly, open source projects started as someone's dream. They had a vision of what it was they wanted to do and they were committed wholeheartedly to fullfilling that dream. When you have a strong vision of what your dream is, you will do what is best to fullfill that dream. Suddenly, meetings, discussions and tedious documentation and process are merely tools and steps towards accomplishing that dream. The people becoming involved with the open source project are there not because they have to fill time for a paycheck but because they too believe in the dream.
Contrast that with what most corporate projects are. Most corporate projects are forced on the employees with little discussion. The employees are mostly drones to carry out the tasks and orders of someone else's idea. Even worse is when you realize the people calling the shots, the ones that SHOULD be most passionate and have the strongest vision of the project don't really care or understand it since they are usually their to fill time for a paycheck just like the rest of of the company. Now all of a sudden tasks like communication, meetings and process become a real drag because you are no longer working towards a dream of yours, but, rather carrying out orders for someone else who most likely doesn't care much about the project either but still needs to look good to his/her boss.
Runesabre
Enspira Online
In general, bugs found and resolved in-house cost 10% as much as bugs found by customers. (I'm agreeing with you.)
I feel fantastic, and I'm still alive.
One caveat I would put forth is that projects that don't start with the philosophy of "The fastest way through a project is the right way" often get the incorrect idea that this is simply idealogical hooey. In order to really see this philosophy play out correctly you have to start with this as a core philosophy and not towards the end of the project when there simply isn't enough time to repair all the damage.
Runesabre
Enspira Online
Runesabre
Enspira Online
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Rising to one's level of incompetence is also known as the Peter Principle.
Another important variety of this is the septi tank theory of organisation: According to this, "the biggest lumps float to the top"...
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.
It strikes me curious why the authors choose Gimp and GnuCash as sample project to layout their theory. The ODSL survey (http://www.osdl.org/dtl/DTL_Survey_Report_Nov2005 .pdf) proves that even Linux users still wish for Photoshop instead of Gimp and it proves together with the Novell's Cool-Solutions web site (http://www.novell.com/coolsolutions/feature/16798 .html) that users prefer other cash applications than GnuCash.
. html) I don't see a possibility how it can eventually overtake ClosedSource development.
Does this prove that OpenSource development is wrong? Or is not done properly? I think not, the way how OpenSource development is done is fine but it shows some other problems. It shows that OpenSource development has a leader problem, a problem in which direction (towards which goal) the development should head.
So if OpenSource doesn't head into a common direction as e.g. outlined here (http://lxer.com/module/newswire/view/54009/index
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
It has to be mentioned that all the top OpenSource project are in some kind heavily sponsored:
... ... ...
8 905&cid=14833101
- 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
See http://wyoguide.sf.net/papers/Cross-platform.html
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".
What a load of BS!
... excuse me, I need to barf ...
...
What it seems the OS developers, or their advocates, have learned best over
the years is how to congratulate themselves, portray banalities as deep
insights, and point to the handful of OSS projects that aren't defunct, or
*totally* dysfunctional, or in *total* disarray as paradigms of the the highest
quality project management.
As someone who has depended on OSS software for several decades, and suffered
through the incredibly slow, broken, chaotic manner in which those projects
develop, I can hardly find words to express my disgust with this article.
What really needs to be discussed is how to get OSS projects to adopt even
a modicum of the discipline required to produce release quality software.
For this, they must learn form the commercial developers. In fact, they might well
start with the popular books from IBM and Microsoft developers
But then again, this article isn't about teaching anyone anything, is it? Let's
wish the authors great success with their consulting business.
I know of a country bordering both the atlantic and pacific, that started to rack up the national debt as soon as its current rightwing president got to power. But can a country go bankrupt?
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 war on your own and other countries' people, you end up with the effects of that: dead people, and a larger percentage that hates you so much they don't mind killing themselves if they kill enough of your people. (oh and let's not forget the fat cats that trive on defence contracts alone)
So both systems genereate a percentage of parasites/fat cats/lazy asses. Unemplaoyed people on wellfare are just as unproductive as soldiers in the army, but a lot cheaper to maintain. Why would you prefer the system that delivers death and destruction?
This space is intentionally staring blankly at you
The concepts presented are widely documented elsewhere. The stated rules are almost the same as the XP mantra. I also recommend Steve McConnels book "Rapid Development: Taming The Wild Software Schedule".
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. ;-)
"The Peter Principle" states that a person will be promoted until they are put into a job they cannot handle (their level on incompetence). You might be a competent tech lead, but an incomepent PM. you might be a competent PM but an incompetent Asst. Director.
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, and not all that long of a book. Check it out.
My Heart Is A Flower
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.