Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open-Source Development 'Faster, Better, Cheaper'

Posted by michael on from the plan-for-success dept.

David Hart writes "Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering -- Walt Scacchi of the University of California, Irvine, and his colleagues are conducting formal studies of the informal world of open-source software development, in which a distributed community of developers produces software source code that is freely available to share, study, modify and redistribute. They're finding that, in many ways, open-source development can be faster, better and cheaper than the 'textbook' software engineering often used in corporate settings."

7 of 150 comments (clear)

  1. Whoops! by Space+cowboy · · Score: 5, Funny

    I think a better strapline could have been thought of - this was the same as NASA's, yes ? At least sufficiently similar to attract attention, and then it all went pear-shaped...

    Consipiracy theorists will no doubt don tin hats and say it's all a front to associate Open Source with bad karma :-)

    Simon

    --
    Physicists get Hadrons!
  2. surprising? by tomstdenis · · Score: 5, Insightful

    Textbook soft.eng is about making money and how to prevent from being sued [e.g. you do what you agreed todo].

    While OSS development [well freelance stuff anyways] tends to be more about actually getting work out the door. Don't like this particular OSS, fix it or find other stuff. E.g. no pandoring to stupid demands of market droids.

    Tom

    --
    Someday, I'll have a real sig.
  3. Definitions! by joel.neely · · Score: 5, Insightful

    In the context of development, "faster" and "cheaper" are somewhat well-defined, but "better" is simply too fuzzy. There are many qualities which contribute to "better", and some of them are in conflict (e.g. "more profitable for the marketer" vs. "easier to get bugs fixed"), depending on the value system of the speaker.

    We need to be more precise in our terms when defending or advocating open source, else we'll appear as silly as the suits that think that programmers that expend more lines of code to produce a solution are thereby more productive (or geeks-who-should-know-better who think that execution wall clock time is the only measure of "efficiency").

  4. Fear not, corporate developers by jrm228 · · Score: 5, Insightful
    My limited experience with open source is summed up with this article sentence:
    ~~~
    Not all open-source projects are alike, however. A small number of open-source projects have become well known, but the vast majority never get off the ground, according to Scacchi.
    ~~~
    Open source is obviously faster/better/cheaper when 1000's of people donate their time to a single project. The only open source project I've been involved in was a collaboration among several corporations, all of which wanted to leverage each other's resources, but none of which could really contribute their own.

    There's nothing like money to motivate people to work on a project for which people aren't willing to donate their time.

    Personally, I'm not convinced speed is related to developer quantity. There's too big a variation in productivity between experienced and amateur developers.

    I'm also not convinced open-source is right for all types of software. How many open-source developers you know that conduct large-scale usability tests? How many open-source developers go around interviewing end users? When the developer and product consumer is the same, open-source makes much more sense to me.

  5. Ironic by Anonymous Coward · · Score: 5, Interesting

    These guys are trying to formalise open source development practices and write a new textbook for corporate software engineering. Here's the catch, open source development models work because they are informal, because their is no pressure other than that of your respected peers.

    When they're done they may like to do a little research on 'irony'.

  6. Most of the times this wouldn't work.... by cREW+oNE · · Score: 5, Insightful

    This setting wouldn't work most of the time, IMHO.

    For open source to work there needs to be a certain public interest in the software, and there need to be developers in the group of interested people. Opening up software that nobody wants to look at or develop further is totally pointless.

    A lot of software out there (I dare to argue it's the majority of the software out there.) is simply too boring or to business-specific to benefit at all from open source.

    --

    +++ATH0

  7. There are some reasons for formal processes... by Anonymous Coward · · Score: 5, Interesting
    We're working on a complete re-do of an existing product. The first version was nothing more than a gui demo, but marketing said "can you make it do this", and "can you add that", and so on.

    The (mid-level) programmer involved just added feature after feature, worked many long nights and weekends and ended up with an unmaintainable nightmare of custom software for the major customer.

    I was asked to help with some new features, took one look, and said to myself "no way I'm working on this mess" and spent some time coming up with a more generalized architecture [1].

    This time around, the first thing we did was get marketing requirements. We turned this into a functional spec, sent it out to marketing and project management to be reviewed. After that they are going to sign their goddamn names on the goddamn front page of the functional spec, and we're going to build it. If they say "but we need x", we (the engineers) can say "should have thought of that earlier, we can try to get it into the next release in two months [2].

    I know it is kind of a CYA [3] approach, but a paper trail puts the pressure on marketing and product management to GET IT RIGHT.

    So, sure, the scratch-my-itch[4] kind of development comes up with some very good stuff, but the old-fashoned waterfall (requirements-> design-> implement) keeps people honest (or at least points out what parts of the company need to do a better job).

    One more (slightly unrelated) point. Get the GUI in front of marketing as quickly as you possibly can! Those guys can't think unless they have something to click.

    -- ac at home

    [1] I know it sounds vain. Actually, I'd worked on teams designing very similar systems twice before, so we'd thought out a lot of the details already, so it was easy to see the common vs app-specific parts.

    [2] I realize that if a big customer wants feature X by next tuesday we'll have to do it, but it ends up being a failure of marketing and product management, not engineering. We're the heroes, not the villians.

    Plus we've got a pretty good idea of how the customer is going to use the system (since we've got one version out there now), so the software will do a lot more than just what's in the functional spec.

    [3] Cover your ass.

    [4] In some part this project is one. After going through two design phases and having both projects cancelled, I really wanted to put the basic platform together and prove to myself it would work. (So far so good).