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."
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!
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.
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").
Open source projects attract people who have an interest, and often a talent, for the project. The same can't be said for many corporate projects, where you may be shoveling shit, but you're being paid to shovel shit.
Mea navis aericumbens anguillis abundat
~~~
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.
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'.
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
Uh. This is a feature, not a bug. As far as I know, it's turned off in most if not all vendor-supplied kernels. It can be turned on when compiling the kernel. However, it can be pretty useful when debugging something that makes the possibility of lockups large.
By the way, it's more than just rebooting you can do this way. During a lockup, you can sync your disks (alt+print screen+s), unmount them (alt+print screen+u), and kill everything on the current virtual console (for example X) with (alt+print screen+k). This is useful when you are running with less than stable drivers, X11-setups etc, but I would not recommend it instead of trying to get to the bottom of the stability problem.
I would recommend it hands down to having to push the power button, though, it can actually help saving your data.
That's debateable. What you need to debate is what else is doing what they are doing.
Mozilla: It's making a standards-compliant browser. It is clearly done faster, as it's the only one out there. Fairly self-evident.
Wine: It's reimplementing an OS without access to the internals. What are you comparing that to for purposes of determining its speed? I personally think it is occuring extremely fast, all things considered.
Linux: Seems to be developing fairly on-par with other kernels. Yes, it took a while to get to where it is now, and had some comparitive slumps, but where was everything else when Linux started? Unix was ahead. Windows was DOS, right? MacOS was an early classic one? I really don't know, but it seems fairly close.
Consider this: It's ahead of Windows on most high-end stuff, now, and has been on-and-off for a while.
MacOS had a speedy jump in progress with OS-10, but that was also open-source development (BSD base, partially open still) so that's just an agreeing argument.
As for commercial Unixes, I haven't a clue, so I won't talk about them.
gcc: I haven't a clue. I really don't. Just noting it because you did.
For my own example, MPlayer: MPlayer started about the same time that media players got big on other systems. Without having any source information for codecs and so-such, it's stayed just as far along technically. Ever since it's been around, I've been able to watch things about equally well under any OS, except DVDs.
The main area I see OSS lacking is in interfaces, which is why MPlayer is such a good example. Good God, is that a bad interface. Not the worst, no, but it tries. I'd say that is a part of the 'better' thing.
OSS is good at doing most of stuff, just not at getting EVERYTHING together. For a lot of things they do the technical end while the interface lags, or they do the interface and it's got a buggy back-end, or they make something really good but it is so messy inside it needs a total re-write to add anything.
I don't know how that compares with the problems of closed source, as I've never worked on it, but those are just the way I see the issues.
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).
You forgot one reason to do open source.
I'm a good programmer, I can write an OS, windowing system, Word Processer, etc all by my self. Well in theory, doing all that alone to even the quality of Windows 3.0 and WordPerfect for Windows (which sucked in those days) is close to byond the time I will live, and in the meantime I don't have programs to use.
When I work in open source I can take advantage of other's work. So I write [part of] the VM for the kernel, while others write everything else to make the kernel work, more others right the libraries and utilties, and still others write my windowing system and word processer. Put it all togather and I have free programs to use, and the ability to change anything. So last year I re-wrote the VM that everyone is now using, this year I can direct my attention to nethack making it even better.
In other words: don't overlook the value of working with others.
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.
There is a mentality by some, not all, in the OSS world that anything closed source to hit their computers is bad. I was at a convention recently about 3D animation software. One of my big consulting clients is a medium sized arcitecture/graphics firm. They had just abandoned some very cool software designed to run on the DEC Alpha platform for Maya and they chose to run it on Linux. Why? They tested Maya on both Wintel, Linux on x86, and Macintosh. The designers seem to like it on Linux and it was stable. Plus Linux would run on their existing hardware without any problems.
Anyway, at this convention, there was one Linux Zeloat there that couldn't "Believe you would tait the pureness of the OSS Linux with that commercial crap. Haven't you heard of Blender?" At first I thought he was joking.
I had used blender for personal use since 1.8. Yes, Blender is a good program, but even for someone like me the learning curve is steep as hell. Plus you have to export to a 3rd party app for rendering with raytracing. Blender is comming along and has had some nice features added since reaching OSS land.
However, 3 of their Graphic Artist had previous experience with Maya and could help the other two learn the program. The simple fact this company was going to ditch Windows for Linux should be a victory for the OS and OSS land. But the mentaily of "All OSS or non at all" held by some is a mistake.
Look at GIMP. I know 2.0 is scheduled for release soon, but GIMP today compared to that of 1999...it hasn't changed much. Back when I was using Photoshop 4 & the early days of 5, I thought for sure that GIMP would leap frog them or at least improve to the point of being an equal. It almost appears that GIMP developement stood still while Photoshop 6 and then 7 was realeased with many great new features. Maybe 2.0 will see some improvements, but that is one example of where OSS hasn't surpassed its commerical counterparts.
If Linux is going to thrive on the desktop, it will need supported non-OSS software from people like Adobe and Macromedia. I will pay for good software, and so will many others. Free is looked upon with a keen eye, Econ 101: THere is no free lunch.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.