Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

What Corporate Projects Should Learn From OSS 110

Posted by ScuttleMonkey from the help-spread-the-infection dept.
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.
This discussion has been archived. No new comments can be posted.

What Corporate Projects Should Learn From OSS More

What Corporate Projects Should Learn From OSS

Comments Filter:
  • 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.
    • 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 wa

  • Ridiculous! (Score:4, Insightful)

    by AutopsyReport ( 856852 ) on Wednesday March 01, 2006 @06:25PM (#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.

    • 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.
    • 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.
      • "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,
    • 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 late
    • 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 l

    • 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,

    • 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 qual
    • 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 :)

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

    • 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 even

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

    • 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 corporat
  • 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
    • 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!
    • Tell the truth all the time good thing, people are afraid

      Trust the team trust is a good thing

      Review everything, test everything don't trust blindly thought! (and that is not to blast the other, review, critic, challenge, that is what get someone to move higher, evoluate) -- I hate it when people are afraid to review, or change something because it is already done. It is not a valid argument IMHO and it often cost more to act this way.

      All developers are created equal well as anything in life, created I
  • That all code should be "production quality" code. There's no excuse to have internal tools written like crap, and unmaintainable.
  • 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 p

    • Re:Great article (Score:1, Informative)

      by Anonymous Coward
      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 commod

      • Re:Great article (Score:2, Informative)

        by chris_mahan ( 256577 )
        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 n
        • 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 s
          • Ah, I'll grant you that. The code may not be looked at by more people, but it has the potential to. So if the code is recognized as some very clever and very useful code, more people will look at understanding and improving it.

            In the corporate world, the code will be looked at only by the next unlucky stiff who's been assigned to "enhance the product" and he'll most likely have no contact with the original coder, so he'll code the enhancements his way and the code will start to look like some of the French
  • 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.

  • Meanwhile in the 70s.... (Score:3, Insightful)

    by MosesJones ( 55544 ) on Wednesday March 01, 2006 @06:32PM (#14831030) Homepage

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

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

  • 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.
  • 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
    • 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,

    • Hopefully you'll never have to support the DB interface. Hopefully you won't go on vacation for three weeks and forget how it works. If it's not documented, then it's not done.

      Accurate documentation does not take long to write. Lack of accurate documentation is a sign of fuzzy thinking. Fuzzy thinking is often an indicator of poorly thought out code (design, business requirements, etc.).

      Good documentation takes a while to write. Good documentation is appropriate for non-core audiences and long-l

    • 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 cos

    • 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 professio

      • Re:Lots of bad information (Score:3, Insightful)

        by mce ( 509 )
        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

  • Step 1 ... (Score:2, Insightful)

    by Reelworld ( 120784 )
    ... 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 pro
  • 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.)

  • 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
  • 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.
  • 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.
    • In general, bugs found and resolved in-house cost 10% as much as bugs found by customers. (I'm agreeing with you.)
    • 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.
  • 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 corpora
  • 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.

  • 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 communicat

  • Why management has a different viewpoint (Score:3, Insightful)

    by DickHodgman ( 265853 ) on Thursday March 02, 2006 @01:39AM (#14832897) Homepage
    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.

  • A very trashy and biased story (Score:1, Interesting)

    by Anonymous Coward
    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 i
  • 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. ;-)

  • People "vote with their feet." (Score:3, Interesting)

    by shadwstalkr ( 111149 ) on Friday March 03, 2006 @02:45AM (#14841041) Homepage
    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.

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close