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.
At one of the major corps(5000+ employees) that I consult
for, we wanted to integrate the shareware version of Linux into our
server pool.
There is no shareware version of Linux it's open source.
I took it upon myself to configure the
system from scratch
And herein probably lies your problem. Buy a boxed set, don't fuck about with it and you'll probably find your problems go away. I doubt whether a Forune 500 company would object to paying $90 for a package they can install on an unlimited number of servers.
Hmmmmmm..... Deep fried and look like Squirrel.
Please mod me (and parent) offtopic and/or redundant...
Press alt, print screen and b at the same time. Your oh so stable Linux will crash. It may be flamebait to the zealots, but it is also Informative and Insightful, so mod this accordingly.
If you press SysRQ+B, the kernel will send a reset instruction to the processor, effectively resetting your machine without syncing the fileystems, corrupting them.
Please do read the documentation before playing with the MagicSysRQ key.
Anyway, this doesn't have anything to do with the topic (FLOSS development techniques)
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
Maybe a little old but hindsight is better sight.
From my own Web page
PROBLEMS IMPORTANT TO SOLVE
Attention Getting Points
------ FROM ------
COMDEX SPRING and WINDOWS WORLD 95
Power Panel - "What's Wrong with Software Development"
** In The U.S. Only **
$81 Billion = 31% of software development gets cancelled before complete
$59 Billion = 53% of software development has cost over-runs of 189%
16% success - project success and failure ratio
61% customer requested features and functions make it in
Maintenance and repair is where most of the U.S. dollars are going,
instead of new, better, easier to use software.
---- Overall ----
Problems - all-around lack of complete documentation and weak training, faulty user input and feed back - self contradictory user request, lack of project leadership between developers and users, management created problems and low quality control standards, feature creep and software size increase, advancing technology rate of change and lack of general standards, solutions around the corner but never arrive and our tools are better than theirs attitude, lack of a value chain structure for value added abilities, failure to produce a functional model before coding and constant remodeling, etc.
Solution directions - code re-use, object oriented programming, component-based programming, distributed components, better tools, better programming methodologies, leaner software, a splitting of code writer types into two catagories - architects and assemblers, better effort to establish a working vocabulary between developers and users so users can in some way lead development, etc.
---- A Few Comments from Panel Members ----
A culture needs to evolve that respect software engineers as crafts-people. Writing code is not just writing code but like the field of writing where you have technical, creative, documentary, etc., there are different types of code writing. (Authors' note: I agree with this but also realize end users are even more specialized in what they need and do. Respect for the end user needs and abilities is needed even more so. Without respect given to the end user, the software engineer will not be given respect in return.)
A fundamental change in the programming environment needs to happen that allows the tools to work together more. (Authors' note: the panel member making this comment, did not specify what tools or who the tools would be used by. It was a very general comment pointing to a fundamental programming environment change. A lead in to the concept of componet programming. But, there was no recognition given to the concept of componet software or componet applications. At least not in the sense of being outside of "plugins". Read on!)
Jokingly - one of the best ways to copy protect software is to put it in a dll, give it an obscure name and put it in the windows system directory. Because you'd never find it. (Authors' note: This does not make it any easier for the end user in keeping their system organized, clean and optimized. This attitude of constraints, though humorous, cost end users alot.)
The meaning of "intellectual property" became questioned. Did it mean you take the best ideas or something owned? (Authors' note: it was the panel supporting "best ideas" but wouldn't the correct term for this use be "intellectual value" rather than "intellectual property"? What would happen, regarding this, in a court room? The audience member whom brought this up, was a bit angry about the distortion. Her question was: Is it the developers whom are creating the problems? And what are the developers going to do about it? The responce was "that's not the problem!")
Users shouldn't develope software but know, better than the developers, what they want and need. (Authors' note: users don't have the time to write code, it's not their job or duties!!! I can cut the lawn, I know h
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.
If it's active on your machine and you don't want it, you don't have to recompile the kernel. Just type sysctl -w kernel.sysrq=0 at the console to deactivate it right now, and put kernel.sysrq = 0 in your /etc/sysctl.conf so magic sysrq will be deactivated automaticly next time you boot.
A big problem with this whole idea of OSS, and then measuring it against traditional metrics, is the issue of motiviation/demand.
In a corporate setting, programmers are coding because "That's my job". People say "I am a programmer". They get paid for it, money, career, fullfillment, retirement, are the goals.
In the OSS world, the motivations are vast. For some its fun. I like to program. Why not give away a piece of my hobby to others? I don't need it. For some its profit. If I write this program maybe a corporate sponsor will back me, or maybe individuals will donate to me. For yet others its anti-someone-else-ism. If I write this it'll be the gutter for Microsoft.
This is all well and good. The problem is that in the first setting it is much easier to get someone to do something hard and unrewarding. Write a device driver for a crappy USB chip? Yessir. Write and update a comprehensive design document? No problem-o.
In the OSS world, there is a glut of people working on fun projects - or projects that are rewarding. You have dozens of people working on chat programs. You have a strong number of people working on projects that will thumb MS in the eye- OpenOffice for one.
But in the OSS world, there isn't a lot of work going into unfun projects - and the work that is being done mostly by corporate sponsors (who can say, again, 'do this' to a programmer for hire).
Examples come to mind: in the closed source world there is plenty of really good desktop publishing software. In the open source world, it's not a fun project. It's hard. It requires lots of industry knowledge. It's a small market and therefore a small pool of programmers. It's unrewarding - you won't have a cult of personality like Linus. Another example already mentioned is device drivers. Even when documentation exisits getting a really nice high-quality device driver is somewhat rare. It is easy to cut corners and implement only what is needed for a specific job.
This is an important thing. A lot of small companies I've seen have been turned off about using OSS as a development model because expectations are high. Just because a product is released as OSS doesn't mean developers will flock to aid the project.
This disparity in motivation can lead to a hard time quantifying results. A project that is fun, high profile, or highly profitable will have excellent results compared to a typical corporate project. A project that is non-fun, not likely to go anywhere, but somewhat more "down and dirty" is likely to fall far far behind commerical development standards.
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.
Faster and Cheaper go hand-in-hand, but are always the bane of that 'Better'.
Oh well, two-out-of-three ain't so bad.
So, anyone want fast, cheap sex?
My number is, oh, hi honey...no I wasn't gonna...really......crap.
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.
Eric Raymond breaks this topic down in "The Cathedral and the Bazaar", and excellent read. the opensource model is proven. the number of successful real-world projects built on the model have been belabored enough. it is the metrics you follow to adapt your particular project to it that matter, and those ,ultimately, lie with you.
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.
No offense to anyone but I would like to see this study done by people who actually 'do' rather than people who just study. There is a big difference in the understanding of large project development deployment by someone like IBM (who does open source) vs someone at some university somewhere who does not have the full grasp of real world project/product development under their belt.
First of all, to be able to compare faster, better, and cheaper, you have to assign a value to the amount of engergy spent on a given project such that the resources expended (i.e. brainpower, electricity, etc) are equal on a per programmer basis. Then you have to create a project that requires multi-discipline engineering so that you are removing the quickie one/two man projects from the equation. Then you have to measure the output of the project on a non-commercial penetration, i.e. not how much revenue is generated but how many copies are in use and how is it beneficial. Additionally you should add the amount of energy from the project(s) that result in failures. Having multiple, parallel projects (commercial or otherwise) with similar goals and having one fail should result in that energy being added to the sum total of the type of engineering being performed, i.e. if three open source projects fail (or merge, or whatever) in order to create 1 that succeeds then the total energy expended has to be taken into consideration. For the closed source, closed project development team the amount of overhead involved has to be accounted for (including meetings, project managers, product managers, etc).
To just use one aspect of project development as an example, like the testing regiment implemented in a strictly closed source, closed development, commercial venture against that of the open source, open project venture you might find that the resources spent on testing are much higher (or not) for the open source project. Having 1000s of free testers (in an OSS project) is all well and good but that does not guarantee accuracy, depth, and efficiency of testing.
(anecdote ahead). I worked for a company that created java applets (put away your flame throwers and read) which manipulated large data sets and high resolution imagery in a browser environment. In order to test these applets we routinely ran them and the back end fullfillment servlets through 40-50 thousand test permutations every time we did a build, we did this with two people running more than 30 workstations. Where are you going to find the discipline to not only set up the tests but run them and generate all the proper reports in the open project community. We are talking about subtle cross browser, cross platform, cross version, even cross language bugs.
Anyhow, its one thing to create an open source project which can be driven by one or two visionaries and requires the input of very few others and another thing altogether to create a large, not so fun project that relies on the input of a large group of disciplined people.
The bottom line is that there is a lot of GRUNT, UGLY, W-O-R-K that has to be done in any large, multi-discipline project and I don't see a lot of that (yes there are a very few) in the OSS/OSP non-commercial community.
I'll pay you $1K if you can demonstrate how the Linux kernel can panic from Bind or Apache crashing.
You never worked with Linux or Apache or Bind. All names you have gathered randomly. Every sentence in your troll is false, like this:
Not to mention the fact that the Linux kernel itself lacks any support for any type of journaled filesystem, memory protection, SMP support,
You don't know what you are talking about. And it's so obvious that I am sure you won't pass any intervew to any consulting company.
I don't know why you are doing this troll. May I guess that you work for marketing department of Microsoft?
Less is more !