Slashdot Mirror
Open-Source Development 'Faster, Better, Cheaper'
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."
You didn't get the point. The article is not about using FLOSS, but about using FLOSS develop methods, and/or applying FLOSS development concepts.
I won't mind if you're using LAMP or W2K as a server, but perhaps it DOES mind if you're using a bugtracking system, public betas, and feedback from people you don't know.
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'.
I can definitly believe better and cheaper. I see that all the time with the OSS software that I use (though not everyone might agree with my definition of better). I hear people talk about faster as well, but I just dont see any evidence of this.
Linux, Wine, gcc, Mozilla. They all took, or are taking, a very long time to develop.
Not necessarily. The fact that nobody would like to work on a store management program for free doesn't mean making it open source doesn't make sense. Somebody working for another company and being paid for it could use it.
Here's the thing: As far as I can see, for most companies the development of this kind of software is an expense they'd love to get rid of, but which is necessary to manage their stuff.
So, suppose a small company that needs its own program for whatever reason. They hire you to code it and say that the problem is that they need the program RIGHT NOW, so unfortunately something usable needs to be ready in 3 months max. It's very unlikely that something good can come out of a requirement like that, unless you find an OSS package, and adapt it for the company's needs.
True. In the end most projects turn into what's good for the users. But that's just because they want to survive too.
However, most OSS "decisions" are user based where as most CSS "decisions" are market based [and sometimes financially based, e.g. please an investor].
Tom
Someday, I'll have a real sig.
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).
I always thought of that... How can open source be more reliable without a project...
I guess the secret is not overspecifying (as it often happens with UML for instance) and building individual, working bricks that can be reused...
Besides, project and implementation often don't go together... I mean, how to deal with different interfaces in a UML description (in the sense of a multi-platform software: MFC, JavaWidgets, GTK) It doesn't work...
how long until
if you are a developer, you don't get paid.
Well, yes and no. I've worked on a number of open-source projects where I got paid. I'm doing this right now. The explanation is simple, and fairly typical in my experience.
What happened was that we needed something, and there was an open-source project that had already developed a good part of it. So we grabbed the source, did a bit of testing to find out what worked and what didn't, and started implementing the parts we needed that weren't there.
The GPL made it fairly easy to convince management that we had better give our improvements back to the open-source archive. But they didn't grumble too much about this. We would just point out that they had got a big portion of the software for free, and saved both money and time as a result. The only decent thing to do is to contribute our improvements, so we should do it even if we weren't bound by the GPL. And we are bound by the GPL, so we'd better give back our improvements. I don't recall any PHB really objecting to this.
The simplest argument to most management types is of the form "You're getting the work of N programmers, but you're only paying the salaries of M of them." And you're getting free testing of part of our product. You can occasionally reinforce management cooperation by casually mentioning "Hey, I just synced our changes to the FOO package, and found that someone else had just added the BAR portion that we were planning to do." This gives your management the warm, fuzzy feeling that they're getting something for nothing.
The only real problem is that you need to draw some fairly solid lines between the open-source portion of the code and the proprietary code that you're writing for the company. But in most cases, this is fairly straightforward. You just keep the source in separate directories, put your changes in the most appropriate place, and keep in touch with the rest of the open-source crowd to make sure that you're not starting a branch.
In many cases, of course, contributing to the open-source code wasn't in the original plan. The official plan was to just use a package from some archive. But sometimes we discover that the package doesn't quite do what we want. With open source, we can fix the problem. We give our fixes back, of course. Then we mention it to management, who invariably just shrug and go on with something more interesting. If there is any discussion, it can be cut short by saying something like "That package saved us several months of development time; spending a day fixing a problem and checking in the changes is a small price to pay for such a benefit."
Even the dumbest PHB can understand this.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
True. In the end most projects turn into what's good for the users. But that's just because they want to survive too.
:)
Yes and no. The way to get a big user base is to do things that users like. So if you want a big user base for your project then get pandering
If you don't care about the number of users but want to make something a specific way because it suits your ideas or because you like the theory of it then you don't have to care too much what other users think.
There are lots of open source projects in both groups. The big ones tend to be at least to some degree the ones that care about pleasing their users.. they're big because they want to be after all... but that doesn't mean all the others don't exist.
Without being able to define "better" it's impossible to determine "faster" or "cheaper," since you may very well not be comparing similar end results. You need to be able to quantify the technical aspects and assure at least a 1:1 mapping of functionality before you can go around claiming "faster" or "cheaper." You might have just spend more in less time to produce something that doesn't do half as much. Woo!
Textbook software engineering is about identifying what the client needs, and delivering it on time and on budget. What is sad is that we still fail in that objective a good portion of the time.
Ironically I don't think that it is true at all that OSS development is faster or more efficient. Basically coding is coding, so I don't see anything explicit to OSS that will make us faster directly.
On a large project however we might be more carefull with our coding, as many other developers will see the code. This may initially be actually slower. However, more care and less defects has a longer term benefit in not needing so much bug fixing. However, I don't see that benefit unless the project is at a size that other developers will see your code.
It is certainly less efficient in terms of manpower, a business can at least concentrate their resources, have people work on a project full time. I can't imagine employing a copy of the OSS approach - ie distributing specifications around the world over the net, and paying people an hourly rate for any work.
The thing is that in OSS you don't pay for time, so you don't have to worry about efficiency. To be clear - this is not a bad thing at all. If you look at many creatures in nature they do not nessasarily optimise efficiency. If what really matters is having excellent security and stability with few defects, then perhaps OSS shows the way.
But OSS is not a rapid applications development approach - and nor does it try to be. Thats not to say that the principles of OSS cannot be applied to commercial development, systems like XP use pair programming for peer review. They also employ unit testing as a stand in for many eyes. In fact test harnesses are great on OSS projects as well.
OSS development is a good idea not because of its efficiency and speed, but because of its quality and freedom.
how can they possibly have concluded that software gets developped faster open source? buesinesses are a lot more organized and know what they want and how they're going to build it.
It depends. As the article points out, a lot of OSS projects never get off the ground at all. So if you wanted to develop something kind of obscure and non-hacker-sexy, like a program for real estate or something, OSS is likely to suck. For a big project that's technologically shiny, OSS is comparable, if not better.
> How many open-source developers you know that
> conduct large-scale usability tests?
Sun does for Gnome and Open Office.
> How many open-source developers go around
> interviewing end users?
RMS does for Emacs. I know that because I tried to submit some code directed at novice users to Emacs. RMS actually asked some compute-ignorant people to try the code, and came with suggestions to changes based on their reactions.
Is it rocket science?
Successful OSS projects have leaders with a vision and who enforce standards. (Torvalds/Linux kernel)
Successful OSS projects are those which many people are interested in. (Linux kernel/Perl)
Successful closed-source projects are those led by leaders with a vision and who enforce standards. (Windoze/Mathematica)
Successful closed-source projects happen because they address a market need and so get funded. (Windoze/Matlab)
In fact, any project succeeds when there's sufficient interest and good leadership.
"Consensus" in science is _always_ a political construct.
Not. The "text book" SE I have seen over the past 25 years, while well intentioned, just slows developers down.
--BLee