Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

110 comments

Sorry! There are no comments related to the filter you selected.

FIRST TROUT! (0)

Anonymous Coward | more than 8 years ago | (#14830828)

I AM A FISH!

Fair enough. (1)

Dukeofshadows (607689) | more than 8 years ago | (#14830850)

Then I say we throw you back.

Re:FIRST TROUT! (0, Offtopic)

P3NIS_CLEAVER (860022) | more than 8 years ago | (#14830887)

second sub-post

Well, (0)

Anonymous Coward | more than 8 years ago | (#14830832)

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.

Re:Well, (1)

AuMatar (183847) | more than 8 years ago | (#14830889)

This would actually be an improvement. Most of the time I get half assed documentation or none at all, and have to figure everything out from scratch. I'd kill for source on most company projects.

Re:Well, (0)

Anonymous Coward | more than 8 years ago | (#14831834)



The problem is there are only so many people who have significantly strong technical backgrounds and good (minimum == store shelves) writing skills is it's a limited group. I'd rather spend my time making sure there's quality code[1] vs. the time spent making usable documentation.

Writing at a level of quality higher than store books is not that difficult. (Authoring|publishing books have a big problem: $$$. Most of the publishers don't pay much because the books don't have a high sell-through. Unless you write a Dummies book or get a book picked up for classroom use, you aren't going to see high sales. I remember dealing with first-time authors who thought they were going to be like Stephen King and make millionz and millionz of dollars. Once people find out they can make a lot more contracting...although WROX books with someone's face on the cover makes for good press when you apply for a job. (this is in spite of the fact WROX made a big belly-flop, was brought to the US, and Wiley speaks of "significantly increasing WROX sales.

Any idea why people consider docs to be a list of examples and each ends with "got it?" and a "wink.gif"?

[2] "Bad programmers can write bad code faster than good programmers can fix bad code (or write good code).
(that goes along with "95% of the people in this business don't belong in it"
and "you don't have to be good, just good enough"

Software (games included) used to include decent docs with their products. This included things such as compilers. Borland C++ 3.1 (early '92) came on thirteen(?) diskettes and more than that many pounds of softbound books in a cardboard carrying case/bookshelf. (I still have Brief and accompanying docs on a flash stick I carry with me) Some game reviewers used to include the quality and quantity of accompanying docs, almost like the joke in college about professors dropping papers down a stairwell. The farther down they went, the higher the grade.

A lot of surveys went out and a lot of marketing feedback showed people didn't really care if docs were included - although they never said why; and to be honest, the software companies saw this (writing docs) as torture. It screwed up the schedule as the docs had to be written by those familiar with the software. Between feature creap and death marches, the software frequently changed (the screen captures certainly did). The product would then be put on hold until the docs were written. Vendors didn't seem to realize they could continue to fix certain bugs although I think they were afraid of cascading issues which would affect the docs.

3rd-party book publishers couldn't have been more happy. Instant market. Kind of like when Reagan deregulated the FCC: no more limits on the length of time on TV which could be used for commercials: infomercials

________________________________________

As far as OS projects & docs go, I think people are extremely motivated to work on the software side of things which are interesting to them and they can always move on if they want to. Everyone knows the code you write today can be improved to do new things tomorrow. That's not true for docs. As soon as mods are made, the docs are outdated. Writing is hitting a moving target. And if there's no motivation to be known as a documenter of OS projects...


Re:Well, (1)

AuMatar (183847) | more than 8 years ago | (#14832173)

Bortland Turbo C++ for DOS was 5 floppies with 1 1500 page manual on C++ and the compiler, when I got it. I learned how to program from that manual.

Re:Well, (1)

jdeluise (804732) | more than 8 years ago | (#14832365)

Hey, me too. I loved that book!

Question (2, Interesting)

Dukeofshadows (607689) | more than 8 years ago | (#14830894)

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?

Re:Question (0)

Anonymous Coward | more than 8 years ago | (#14831105)

At least non-tenured professors get paid, unlike the morons that work on open source.

Re:Well, (2, Insightful)

e4g4 (533831) | more than 8 years ago | (#14831116)

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.

Money (2, Insightful)

wysiwia (932559) | more than 8 years ago | (#14833129)

It has to be mentioned that all the top OpenSource project are in some kind heavily sponsored:

- 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

Most important one: (1)

Musteval (817324) | more than 8 years ago | (#14830858)

Don't pay your programmers.

I'm sure they'll take that one to heart.

Re:Most important one: (1)

P3NIS_CLEAVER (860022) | more than 8 years ago | (#14830955)

Smelly programmers fall for this ruse regularly.

That developers like... (0, Flamebait)

Cornswalled (958023) | more than 8 years ago | (#14830869)

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?

Re:That developers like... (0, Flamebait)

molarmass192 (608071) | more than 8 years ago | (#14831136)

I love this communistic bullshit line. How in the fcuk do you equate open source software that is free as in speech, not free as in beer, as being communistic? Tell me, which current system of government is (was) defined by free speech and transparency?

Re:That developers like... (0)

Anonymous Coward | more than 8 years ago | (#14831250)

It's even funnier when you realize that there is nothing inherently wrong with communism. Just that open source was called communistic to create a negative reaction from Americans. It would be even funnier if in China they badmouth OSS as capitalistic! :)

Re:That developers like... (2, Insightful)

LegendLength (231553) | more than 8 years ago | (#14832808)

How in the fcuk do you equate open source software that is free as in speech, not free as in beer, as being communistic?

From http://www.answers.com/communism [answers.com] :

"A theoretical economic system characterized by the collective ownership of property and by the organization of labor for the common advantage of all members."

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.

Re:That developers like... (1)

larry bagina (561269) | more than 8 years ago | (#14833632)

How in the fcuk do you equate open source software that is free as in speech, not free as in beer, as being communistic?

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.

Re:That developers like... (0)

Anonymous Coward | more than 8 years ago | (#14831460)

Hahaha...I just read your Livejournal "blog". Very good! Quite the troll, you are.

The learn there is no spoon. (1)

Anonymous Crowhead (577505) | more than 8 years ago | (#14830890)

Only forks.

What economists should learn from OSS (0)

Anonymous Coward | more than 8 years ago | (#14830906)

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.

Re:What economists should learn from OSS (1)

LeonGeeste (917243) | more than 8 years ago | (#14830988)

Er, kind of an overstatement there, kid. "Modern economics" does not hold as a "foundation" that "people won't do anything unless they're paid". In fact, that pretty directly contradicts "modern economics", which extensively uses marginal analysis [wikipedia.org] . Marginal analysis would consider every kind of incentive to perform actions, and only add you can get "marginal cases" to offer support by paying them. Ask yourself -- why isn't there "open source" food production beating out for-profit food enterprises? Or for TV's, engineering work, etc.? Could it be that OSS can be distributed to everyone at little cost and without sacrificing the original? Claiming that F/OSS is proof of a more general argument that *all* production can be sustained by people offering work for free is an extrapolation well beyond that justified by the evidence. If it were true, communist organizations would be far more successful than they currently are.

And as for "modern economics" "running the country"... I wish. Pretty much every economist cringes at pretty much every government policy, and only change their minds after going on the payroll. Check out economists supporting the minimum wage only *after* joining up with Clinton.

The pot calling the kettle black (0)

Anonymous Coward | more than 8 years ago | (#14831168)

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.

Re:The pot calling the kettle black (1)

LeonGeeste (917243) | more than 8 years ago | (#14831263)

The assumption that the grandparent advocates communism is as bad as the assumptions you accuse it of making.

What do you call an economy in which all goods are provided at no cost and with no expectation of direct compensation therefor? I was pointing out the errors in extrapolation to non-profit production of all services.

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.

Cool, which government services did they privatize? Oh, that's right: none. How much has government intervention in the economy contracted under the Bush administration? Negative a lot. (That's an increase.) Doesn't sound like a shift to a free market, privately run economy. And what does private ownership have to do with this? "Private" does not necessarily mean "for-profit" -- in fact, it usually doesn't. Open source projects *are* privately run; they merely don't assert copyright or patent control over the source code. I'd love for the rest of the economy to be run like an open source project -- you only have to get involved to the extent you want to.

Let's run through the economist/current administration disconnect:

Minimum wage: economists hate, government loves.
High marginal tax rates: economists hate, government loves.
Complicated tax code: economists hate, government loves.
Well defined property rights: economists love, government hates.
Free markets in the production of goods and services: economists love, government hates.

Take another hit off that bong.

Re:The pot calling the kettle black (0)

Anonymous Coward | more than 8 years ago | (#14831429)

George Bush goes to a primary school to talk to the kids to get a little
PR. After his talk he offers question time. One little boy puts up his
hand and George asks him his name.

"Stanley," responds the little boy.

"And what is your question, Stanley?"

"I have 3 questions. First, why did the USA invade Iraq without the
support of the UN? Second, why are you President when Al Gore got more
votes? And third, whatever happened to Osama Bin Laden?"

Just then, the bell rings for recess. George Bush informs the kiddies
that they will continue after recess.

When they resume George says, "OK, where were we? Oh, that's right:
question time. Who has a question?"

Another little boy puts up his hand. George points him out and asks him
his name.

"Steve," he responds.

"And what is your question, Steve?"

"Actually, I have 5 questions. First, why did the USA invade Iraq
without the support of the UN? Second, why are you President when Al
Gore got more votes? Third, whatever happened to Osama Bin Laden?
Fourth, why did the recess bell go off 20 minutes early? And fifth, what
the hell happened to Stanley?"

Idiots (0)

Anonymous Coward | more than 8 years ago | (#14830923)

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??!!

balance works everywhere (1)

Pavel Stratil (950257) | more than 8 years ago | (#14830936)

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.

OT trollfeed (1)

nietsch (112711) | more than 8 years ago | (#14833836)

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?

There are many things OSS projects can learn... (0)

Anonymous Coward | more than 8 years ago | (#14830947)

...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! :)

Re:There are many things OSS projects can learn... (0)

Anonymous Coward | more than 8 years ago | (#14831066)

Oh and I forgot: Spell-and-grammar-check before you distribute! :)

Re:There are many things OSS projects can learn... (1)

charlesnw (843045) | more than 8 years ago | (#14831108)

Is that you Daryl? :)

Re:There are many things OSS projects can learn... (1)

LordLucless (582312) | more than 8 years ago | (#14831395)

5) Force all your customers to wear fancy dress so that you don't need to perform any sort of grammar check when you post lists on slashdot.

Ridiculous! (3, Insightful)

AutopsyReport (856852) | more than 8 years ago | (#14830962)

Let me break this argument down categorically.

"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! (1)

robertjw (728654) | more than 8 years ago | (#14831109)

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.

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.

OTOH, this is one area where F/OSS has found a unique solution. Take, for example, the Linux kernel. It doesn't seem, from what I've read and seen, that Linus has tremendous people skills, but he has a kernel development team that has produced an amazing product. How did he do this? I think a major reason for his success is he doesn't have to deal with all of the day-to-day managment issues that a manager in a corporate setting would. He doesn't have to worry about sick time, tardiness, body odor, etc... Most of his time, work and management is focused around the project. If corporate software companies could find a way to create their development teams in the same way and just pay them based on their contributions to the project it could be a significant improvement for software development.

Re:Ridiculous! (0)

Anonymous Coward | more than 8 years ago | (#14831244)

He does have a bunch of willing and able employees, something you may or may not find outside of FLOSS.

Re:Ridiculous! (1)

antispam_ben (591349) | more than 8 years ago | (#14831257)

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.


Not sure if it's what you mean, but this sounds a lot like The Peter Principle.

Re:Ridiculous! (0)

Anonymous Coward | more than 8 years ago | (#14831285)

you've taken someone out of a position they excel at, and put them into a position they need to learn

The Peter Principle [wikipedia.org] ?

Re:Ridiculous! (1)

cowboy76Spain (815442) | more than 8 years ago | (#14831324)

Just to add one more reason to the post:

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 later. In fact, many organization with better knowledge have QA metrics to avoid a manager too centered in lines of code to slip a poorly documented project.

Also remember that the issue at hand (trading good engineering for development budget) may be too materialistic for an OS defender, but remember that money is behind a lot of development of software that, otherwise, would have not been developed. Think also that it funds efforts far beyond the OS comunity reach (I remember looking at MS site for psychological studies on how to design a better interface, how does the brain work when recognizing written text, etc.)

And, having had to look "under the hood" of several OS projects, I can find that the documentation of many can be improved a lot (IIRC, one of the examples was when I needed to find out when a very large HTTP message failed to be received by tomcat).

The Peter principle (1)

dmartin (235398) | more than 8 years ago | (#14831725)

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.

Re:Ridiculous! (1)

Peter La Casse (3992) | more than 8 years ago | (#14832097)

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.

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, or even fork the project and do things differently. The key distinction is the word "volunteer" and the lesson for software companies is one that if they have any clue, they already know: don't use bad "process".

Re:Ridiculous! (1)

dubl-u (51156) | more than 8 years ago | (#14832107)

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.

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 quality is lowered, new features are hacked in, and people get tired and burnt out. Managers promise that they'll have time to fix things "later", but later never comes, as the next release is already behind schedule. Eventually, productivity collapses and The Great Rewrite happens, starting the cycle anew. If they can stay in business that long, that is.

Successful open-source projects are necessarily different. The focus on quality and sustainability is primary, because people otherwise find something amore fun to do. Hitting a fixed release date with a list of features promised by some clue-deficient marketroid is generally not a factor, because people don't do that for free. Most of the great ones won't even do it for money, which is why so many corporate shops are seas of mediocrity.

Re:Ridiculous! (1)

nigham (792777) | more than 8 years ago | (#14832235)

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.

Rising to one's level of incompetence :)

Re: Rising to one's level of incompetence (1)

Jorgensen (313325) | more than 8 years ago | (#14832876)

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"...

Re:Ridiculous! (0)

Anonymous Coward | more than 8 years ago | (#14832726)

Having worked for many companies in the last 30 years, let's deal with your points one at a time:

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'?

Regardless of where they came from, I find they are ignored in any company as soon as they get in the way of:
1. deadlines - and deadlines are almost always imposed unrealistically. In fact, if it seems that all the above were cut out, deadlines could be moved up and this almost always happens. We don't need all that shit, just get busy coding!
2. more features - as soon as marketing hears about the new product, they start promoting it to customers. If only one customer says: "I'd buy that if it had X" then X immediately becomes a necessary feature. All the above gets scrapped in order to code, code, code and put all those new added features in. From personal experience, if the engineering department knew what it was about, not one of those extra features tacked on after development starts results in a sale!
3. Corporate angst - no matter what, Requirements Analysis, Feasibility Studies, Quality Assurance, Systems Design Documents, and so forth do not add up to anything useful in the minds of management. Eventually, they tire of not seeing anything "productive" happening and force all of that useless shit being dropped to code, code, code damnit!

I have only seen 2 places where the design cycle you seem to think is normal ever came about. One was a university and the second was an Open Source project I was peripherally involved with. Regardless of the source, proprietary engineering (no need to limit this to software) projects never follow through on the planning/design stage.

Which is why all proprietary software is garbage? Reality check?

Reality check indeed! If you use Windows, Office and proprietary Windows software on a daily basis as I do, you must have noticed the buggs and annoyances that have existed in them for many, many years now. I speak of the annoying little "gotchas" that spring up constantly when working with documents and spreadsheets and have for 10 years without getting fixed. I speak of the stupidity of the latest Windows security vulnerability that utilizes filetypoes that fell out of general favor years ago. I speak of the new Vista that promised so much new technology and, in spite of the fact that it is now very, very late compared to its first release schedule, will only meet its delayed release date by foregoing most of that new technology that was promised. and I am not just Microsoft-bashing here: most proprietary Windows software suffers from the same flaws.

Apparantely these authors have never seen the inside of business or safety software.

Apparently you haven't either! As for business software, see above. Most American business runs on Microsoft Office and, as I intimated above and continue to prove every day, it is a constant source of problems, many of which lead to losing completely whatever work was done and forcing it to be repeated! As far as safety sofware goes, what could be more important or a better example of how it is scrimped on than the recent voting machine scandals? Software that is vital to our existenec as a free society that was rushed into production, accepted for use without proper testing and rife with security problems, bugs and a complete lack of accountability or verifiability.

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.

Like hell! See above. Sad to say, I have even participated in such development. It wasn't my decision or my fault that quality was scrimped; hell, it wasn't any of the engineers, it was always management that decided that quality was job none! And all too often, the reasons given were exactly what the parent poster quoted: We have a business to run. Those ideas might work in a perfect world, but we need to concentrate on our code. It would be great to do the project like that, but we just don't have time.

What this article should be discussing is how Open Source has adopted and improved many techniques created and employed by the corporate world.

Perhaps it should be an article that discusses why the very techniques created by the corporate world are not employed by the corporate world? And, again, with 30 years of experience at more than a dozen different engineering jobs, I tell you they are not!

Or perhaps it should be an article on why the techniques created by the corporate world are used most successfuly by the OSS world?

own particular level of incompetence (1)

SgtChaireBourne (457691) | more than 8 years ago | (#14832767)

... 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.
It's called the "Peter Principle [wikipedia.org] ": Each person rises to their particular level of incompetence.

Re:Ridiculous! (0)

Anonymous Coward | more than 8 years ago | (#14833432)

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.


We have no numbers, so this discussion is going to be little less than hot air. Anyway, I bet the bast majority of failed OSS projects (more than 90%) are in fact micro-projects (1 or 2 developers). I have the firm impression that the percentage of medium or large (and thus organized) OSS projects do succeed.

I guess that both things are in fact related, so projects that never pass the micro-project status usually fail, possibly when the original developers lose interests.

On the other hand, there are some projects that are not updated simply because they are finished ;-), or there are not enough interested users.

Re:Ridiculous! (1)

SolitaryMan (538416) | more than 8 years ago | (#14833586)

Comparable to the number of abandoned open-source projects you see not updated since 2004. Corporate or open source, they fail just the same.
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 eventually figure out how it works, they So in this case project is just abandoned. It will never be finished, therefore never used.

In corporate world you can go a very long way with bad design, because you pay people to do the job. And when deadline approaches everyone forgets about design quality. So in this case bad software will actually be shipped and tested by users and fails only if they figure out that software is a crap son enough. If they figure this out much later, when they heavily depend on it, then they are screwed...

Re:Ridiculous! (0)

Anonymous Coward | more than 8 years ago | (#14833657)

I have to agree with the parent.

TFA starts off with "successful open source projects" and then continues throughout including all open source projects as successful, and compares all open source projects to all corporate projects.

There are a few corporate software companies that have been successful and produce great software. HP and IBM are two that spring to mind immediately.

I think truly sucessful Open Source (and the article) took the Best Practices business ideas and used them. But, they've been used in the corporate world for ages.

On the other hand, there are thousands of open source projects that don't incorporate these practices. Many more than the successful open source projects.

TFA is right in that these points need to be incorporated into any software project. TFA is wrong in placing this in a F/OSS vs. Corporate dichotomy. It's unfortunate that the authors have not worked in well-run corporations and are blinded by idealism, though they bring up some excellent points.

One big difference (1)

AnonymousPrick (956548) | more than 8 years ago | (#14830977)

FTFA: 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. Discussions of what features are in and out of scope never seem to take place.

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 (1)

guitaristx (791223) | more than 8 years ago | (#14831154)

You make a convenient over-simplification. The most prominent problem in software development is short-sightedness; making rash cut-the-fat decisions that actually introduce more fat. The ROI for most corporate software projects experiences the same effect as my blood sugar after eating a candy bar: a sudden spike followed by an inevitable crash. Good software development practices ensure sound code today and tomorrow, which keeps the ROI coming in year after year. I do find it interesting that corporate obesity and gluttony is such a problem in light of this analogy.

Project Management Is Project Management (1)

Elvis77 (633162) | more than 8 years ago | (#14830992)

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???

Re:Project Management Is Project Management (1)

squallbsr (826163) | more than 8 years ago | (#14832168)

All developers are created equal

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 .NET (yeah, I wish it was something else too)...

There is no way that you could possibly tell me that bull hocky with a straight face!

What the Commercial World needs to Learn (1)

Krach42 (227798) | more than 8 years ago | (#14830993)

That all code should be "production quality" code. There's no excuse to have internal tools written like crap, and unmaintainable.

Great article (1)

Martz (861209) | more than 8 years ago | (#14831005)

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.

Re:Great article (0)

Anonymous Coward | more than 8 years ago | (#14831041)

I thought it was a rather poor article, too diluted with OSS circlejerking for its good points to stand out.

Re:Great article (1, Informative)

Anonymous Coward | more than 8 years ago | (#14831233)

The only reason the article impressed you is because you, as you admit, have never contributed to OSS as a developer. OSS projects do not work like they describe. Most OSS projects might as well be closed source as only a core group of developers have any idea how to contribute or understand the existing code base. On 99% of the OSS projects, 99% of the work is done by the core development group. "Outsiders" do not contribute code to Mozilla or Apache for example. Thats a myth.

Also, software is not a commodity. A commodity is any homogenous item which may be freely bought and sold. Software is not homogenous. Internet Explorer, Mozilla, Opera are not homogenous. Open Office and Microsoft Office are not homogenous.

Really people, get a grip.

Re:Great article (2, Informative)

chris_mahan (256577) | more than 8 years ago | (#14831755)

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).

Re:Great article (1)

dubl-u (51156) | more than 8 years ago | (#14832906)

I think you have some reasonable points, but I disagree on this one:

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 source, where code is the primary means of communication.

With open source, the code has to stand on its own much more than with closed projects. Even if nobody ever looks at your particular contributions, you are still putting it out there for all the world to see. For me, at least, that makes me more careful.

Lessons Learned: (1)

sakusha (441986) | more than 8 years ago | (#14831016)

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.

Re:Lessons Learned: (1)

Jerry Coffin (824726) | more than 8 years ago | (#14831095)

You forgot one important point:

4. If at first you don't succeed, destroy all evidence that you tried.

Meanwhile in the 70s.... (2, Insightful)

MosesJones (55544) | more than 8 years ago | (#14831030)


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 (1)

tecker (793737) | more than 8 years ago | (#14831097)

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.

Re:One Work: Community (1)

cowboy76Spain (815442) | more than 8 years ago | (#14831208)

Better yet... fire the IT staff and make them work for free (or a symbolic reward/bounty) and call it a community.

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... (1)

Runesabre (732910) | more than 8 years ago | (#14832653)

Open sorce has one major advantage over a closed source product. It is the power of multiple people.

... a community of people that believe in and are self-willingly committed to a common goal.

W00t Fp (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14831104)

Over the Same my eff0rts were

In other news... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14831110)

Linux is STILL for fags.

Re:In other news... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14831711)

And, Windows is STILL for homo-phobes...

What OSS can learn from Corporate Projects (1)

IGnatius T Foobar (4328) | more than 8 years ago | (#14831138)

We can learn from them, too. For example, everyone thinks that our project's FAQ [citadel.org] is far more professional and business-like now that we've changed it from a "FAQ" to a "Knowledge Base."

(It's funny. Laugh.)

When is the meeting? (1)

cubicledrone (681598) | more than 8 years ago | (#14831164)

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.

It's not the software it's the system... (0)

Anonymous Coward | more than 8 years ago | (#14831166)

The software often brings in the system for managing projects, but you don't need the software to manage a project. The biggest problem with most IT projects is that they aren't managed well enough to figure out when a project needs help and it's slipping behind, or even parts of it. A good project management system/software will help you track things like that if it's used through out the project.

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.

Re:It's not the software it's the system... (1)

Futaris (16554) | more than 8 years ago | (#14831296)

But for most people, getting started by using open-source software to track changes, and get used to the process is a big step. Most people don't track a project simply because they don't know how, and/or assume it will take to long to setup (like you said above)

Corporate and OSS are compatible (1)

Carl Rosenberger (449479) | more than 8 years ago | (#14831192)

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.

Lots of bad information (1)

DogDude (805747) | more than 8 years ago | (#14831228)

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.

Re:Lots of bad information (1)

robgamble (925419) | more than 8 years ago | (#14831445)

I agree 100% about the first one. Even developers with similar time on the job often have tremendous gaps when compared with one another. We do not all learn the same, we do not all retain the same, and we do not all have the same creative gifts. I try to put people where they are strong and make sure they know that contribution is appreciated (lots of companies forget that last one).

But as for doing a job right, I DON'T think they meant every project should be done with framework X, service-oriented, maximum abstraction, perfect adherance to all the latest buzz-patterns, etc. I think a quick-and-dirty app *is* done right if you know its architecture and design doesn't need anything else. Ever. But larger efforts need to be planned, sponsors need iterative views into the direction and teams need to be prepared. In a nutshell, give each project the planning and quality effort it deserves.

As the saying goes, if you don't have time to do something right, why would you think you have time to do it over?

Re:Lots of bad information (1)

thetoastman (747937) | more than 8 years ago | (#14831512)

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-lived products.

Accurate documentation should be a requirement for everything. Know your audience and your purpose. Write accordingly.

Once upon a time I wrote some software without using software configuration management principles. I went down the wrong track. I lost three weeks worth of work. I had to burn the midnight oil in order to recover. I will NOT write software (or documentation, or create designs) without practicing some sort of configuration management again.

Software configuration management done right takes almost NO time. Any configuration management process that gets in the way of being productive rather than boosting productivity is the fault of a broken process, not a broken concept.

Throw it over the wall mentality creates a huge negative impact on reliability, availability, responsiveness, and ultimately end user confidence.

Re:Lots of bad information (0)

Anonymous Coward | more than 8 years ago | (#14831883)

All developers are CREATED equal. Equal in rights, not equal in skills.

Re:Lots of bad information (1)

r0ckflite (63420) | more than 8 years ago | (#14832395)

All developers are not created equal. That is a given.

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 cost of fixing crap 'slapped together' code over doing it right the first time.

So each of your points, based on your very limited specialized example, which fails to address true coding, which provides roi. Cause I'm not sure that little db interface that only you use is really a ROI item.

1. He may hold hands cause he needs help to do it right, or possibly to save time cause he's not real good at jdbc.

2. documenting - If it's only a small piece of db code that only you use, he can probably document it in about 1 hour. Be real nice if he gets hit by a bus, hmmm?

3. source code control - He can do it in 3 days, but 2 days into the project his PC hard drive explodes. You didn't have CVS/SVN/Something set up by default that all people use without though. You lose.

So, your limited example sucked. Your theory on ROI is proven wrong by more technical papers than I can shake a fist at. A more real example is you want that crappy db access stuff in 3 days. He gets it in 5 but it is reusable, well written, stored in sccs and has a nice 2 page document stored with it.

I fire you and give him your job. :)

Re:Lots of bad information (1)

bumbledragon (958266) | more than 8 years ago | (#14832710)

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.
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 profession, would you rather have a doctor without a medical degree who has been practicing medicine for 30 years in a small African village or a young doctor who recently graduated from Johns Hopkins Medical? While this is an extreme example, it proves a point. Experience, in and of itself, does not equate to being skillful. A great modern success story is that of Google founders Larry Page [wikipedia.org] and Sergey Brin [wikipedia.org] were both under the age of 30 when they founded Google. I am sure there are many companies which would have dismissed their ideas because they were "inexperienced". With this being said, the article makes a valid point. While that fresh out of college programmer may not have years of experience, they may have a different knowledge base than the experienced programmer. Thus to dismiss an idea of an inexperienced programmer based solely on their experience level is unwise and leads to many great ideas being ignored. I believe the point the author of the article is trying to make is that in sucessful open source projects, ideas are valued over authority.
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.
Yes, you have found a situation where this type of development process may not be necessary. I don't believe the article is talking about simple applications that are of limited outside utility, but about complex applications that require collaboration among many programmers. The article is making a point about how applications should be developed within teams and not about a single person developing a one-time use application. When it comes to developing software within teams, the author makes valid points. Really, the article is about best practices that should be followed when managing any complex projects. Is the methodology described exclusive to the open source community? Absolutely not. Are their failed open source projects? Absolutely. The author is writing about best practices from sucessful open source projects, not failed open source projects. What I think is amazing is how many project managers think things like documentation and collaboration is a waste of time and money. By analogy, when a building is built, we don't think it is a waste of time to hire write up a blueprint before the building is built (requirements documentation). We don't think it is a waste of time to coordinate efforts so the persons putting up the walls don't do their work before the electrical is put in. We don't let buildings be inhabited until a building inspector comes in (quality control). So why do we think we save so much time and money by avoiding these obvious best practices in software development? As an example about how careful design can save money see Correctness by Construction: Better Can be Cheaper [praxis-his.com] .

Re:Lots of bad information (2, Insightful)

mce (509) | more than 8 years ago | (#14833548)

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 profession, would you rather have a doctor without a medical degree who has been practicing medicine for 30 years in a small African village or a young doctor who recently graduated from Johns Hopkins Medical? While this is an extreme example, it proves a point. Experience, in and of itself, does not equate to being skillful.

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".

Step 1 ... (2, Insightful)

Reelworld (120784) | more than 8 years ago | (#14831242)

... write an atricle riding on the open source buzz.
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 .. 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.

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 GIMP? (1)

LetterRip (30937) | more than 8 years ago | (#14831321)

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

Stellman (1)

booch (4157) | more than 8 years ago | (#14831434)

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.)

Playing devils advocate (1)

snakecoder (235259) | more than 8 years ago | (#14831516)


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.

What Corporate Projects Should Learn From OSS (1)

MaXiMiUS (923393) | more than 8 years ago | (#14831575)

Things should be open source. Duh.

Backwards (1)

Ranger (1783) | more than 8 years ago | (#14831634)

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.

The fastest way through a project is the right way (4, Insightful)

Peaker (72084) | more than 8 years ago | (#14831733)

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.

Re:The fastest way through a project is the right (1)

Thing 1 (178996) | more than 8 years ago | (#14832539)

In general, bugs found and resolved in-house cost 10% as much as bugs found by customers. (I'm agreeing with you.)

I agree (1)

Runesabre (732910) | more than 8 years ago | (#14832625)

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.

An interesting read, thanks for sharing... (1)

ursabear (818651) | more than 8 years ago | (#14831831)

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.

The primary difference between OSS and corps... (1)

RoadWarriorX (522317) | more than 8 years ago | (#14831990)

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.

Paul Graham wrote an essay on this too (1)

ghostunit (868434) | more than 8 years ago | (#14831995)

http://www.paulgraham.com/opensource.html [paulgraham.com]

The focus is different though.

Re:Paul Graham wrote an essay on this too (0)

Anonymous Coward | more than 8 years ago | (#14832250)

Very interesting. Thanks for the link.

My company does these things (1)

jonwil (467024) | more than 8 years ago | (#14832036)

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.

My observations after 12 years in the industry. (1)

Runesabre (732910) | more than 8 years ago | (#14832387)

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.

Why management has a different viewpoint (3, Insightful)

DickHodgman (265853) | more than 8 years ago | (#14832897)

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.

Gimp, GnuCash as sample projects? (1)

wysiwia (932559) | more than 8 years ago | (#14833101)

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 [osdl.org] ) 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 [novell.com] ) that users prefer other cash applications than GnuCash.

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. html [lxer.com] ) I don't see a possibility how it can eventually overtake ClosedSource development.

O. Wyss

A very trashy and biased story (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14833375)

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 planet are they from???? (0)

Anonymous Coward | more than 8 years ago | (#14833464)

What a load of BS!

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. ... excuse me, I need to barf ...

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.

Its not just OSS (1)

s31523 (926314) | more than 8 years ago | (#14834138)

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".
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>