Open-Source Development 'Faster, Better, Cheaper' 150
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."
Whoops! (Score:5, Funny)
Consipiracy theorists will no doubt don tin hats and say it's all a front to associate Open Source with bad karma
Simon
Re:Whoops! (Score:3, Insightful)
When big companies use Open Source, the pointy-haired boss is the real winnner.
Re:Whoops! (Score:3, Funny)
Don't you dare associate me with those crazy conspiracy theorists!
Re:Whoops! (Score:2)
As for Jiffy Pop, it's this popcorn that comes in a pan shaped container that you put over a flame and it pops and the top expands and kind of looks like aluminum foil.
Re:Whoops! (Score:2)
Isn't that, like, when your condom bursts?
no that's more like a jimmy-hat pop
Use a hedgetrimmer to take care of your Bush! (Score:1)
Re:Whoops! (Score:1)
Re:Whoops! (Score:1)
I wonder if the "Faster, Better, Cheaper" philosophy will work any better here.
Re:Open source development (Score:1)
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.
Re:Open source development (Score:1, Interesting)
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.
Re:Open source development (Score:2)
Aw, what the hell, it's Saturday morning, I guess someone needs to feed the trolls...
This is in contrast, of course, to the entirely spotless record [google.com] of closed-source architectures [securemac.com] lately...?
surprising? (Score:5, Insightful)
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
Re:surprising? (Score:2)
Actually, I've been noticing much more pandering in recent times. Not neccesarily to market droids, but much the same nonetheless.
Many projects shift focus significantly because some random thing isn't popular with the end users. I don't think this is usually bad, but it has caused some occasional problems.
Re:surprising? (Score:1, Interesting)
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
Re:surprising? (Score:2, Interesting)
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 proj
Re:surprising? (Score:4, Interesting)
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.
Re:surprising? (Score:1, Interesting)
--BLee
Definitions! (Score:5, Insightful)
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").
Re:Definitions! (Score:1, Interesting)
Re:Definitions! (Score:3, Insightful)
Entirely true, but part of the problem is that it is not widely understood that "better" largely is definable, if you're talking about something other then the immediate short term. "Easier to bug fix" will directly translate to "more profitable" eventually. So will "better architecture".
You only get
Motivation (Score:5, Insightful)
Re:Faster, better, cheaper... (Score:1)
Fear not, corporate developers (Score:5, Insightful)
~~~
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.
Re:Fear not, corporate developers (Score:3, Informative)
The 'scratch an itch' [sourceforge.net] motivation of OSS can also motivate people, though not always to the levels that you'd expect. One project I am astounded has not gotten more help is vb2Py [sourceforge.net]. Vb2Py converts Visual Basic applications into Python programs, meaning you can move your VB and Access users over to any platform Python supports -- and change out the database back end in the process. The ma
Re:Fear not, corporate developers (Score:1, Informative)
you need a corporation to "conduct large scale usability tests" or "interviewing end users".
Even so, that would also be wrong.
"large scale usability tests".
otherwise known as betas and pre-releases.
"interviewing end users"
a.k.a. irc, email. feedback.
Open Source makes sense when the product is mature and the consumer wants something that will work,
without any hidden crap in it.
Gnome, Open Office and Emacs (Score:3, Interesting)
> 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.
Ironic (Score:5, Interesting)
When they're done they may like to do a little research on 'irony'.
Re:Ironic (Score:3, Insightful)
Learning how to make a meritocracy work can be extremely useful. All companies try to, at least a bit, by giving employees stock options so they benefit from doing well, trying to give promotions to those who are successful, trying lotsa crap ellipsis.
However, that is very hard. If a company
Re:Ironic (Score:2)
LOL! Most OSS projects I've seen are very formal and well organized when compared to closed corporate ones. [sourceforge.net] (Corporate meaning mostly built for internal use or for specific tasks, I take it?) This is not always the case since some closed ones are run with a high degree of riggor while some OSS is sloppy. Overall, I typically like the results -- including documentation -- that come out of OSS while I'm usually disapoin
Re:Ironic (Score:2)
True. There has to be some flexibility in methodoligies. Strict ones like SEI-CMM are often abused to get a check box on a contact's terms, though the methodologies themselves (whe
Most of the times this wouldn't work.... (Score:5, Insightful)
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.
Re:Most of the times this wouldn't work.... (Score:2)
Re:Most of the times this wouldn't work.... (Score:2, Informative)
There are a lot of area's that need software that programmers just don't give a damn about.
I'll just name one - EU (European Union Government) certiefied invoice management for national governments. Yes, invoices have to meet requirements before they are recognized by the EU, which in turn qualifies them for financial help by the EU.
In general the whole business back-end that needs to deal with all sorts of boring laws and government guidelines is an area so boring and specific that no
Re:Most of the times this wouldn't work.... (Score:1)
Re:Most of the times this wouldn't work.... (Score:3, Interesting)
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 a
Re:Most of the times this wouldn't work.... (Score:2, Insightful)
The first one is that a lot of companies have very, very specific demands. I've worked for governments and large corporations (power and telecom companies) and their demands are so highly specific that no opensource package will even come close to what they demand. So your model might work in some areas, it still will not in others.
The second one is in the adapting part. Apart from the greatest opensource projects, the state of the documentation is pathetic. It
Re:Most of the times this wouldn't work.... (Score:1)
And of course there are many companies with very specific demands. Then, there are many that just need something more or less simple. Say if a company wants a program that does authentication with a smartcard, it's probably not going to be very di
Re:Most of the times this wouldn't work.... (Score:1)
Except, if I were a store, why would I pay an employee to build a system my competitors could freely use? Why wouldn't I have her code a proprietary system that gives us an advantage over them instead?
I do all kinds of very specific tool development for private sector clients and this is how they thin
Re:Most of the times this wouldn't work.... (Score:1)
Contributing some info..... (Score:4, Insightful)
From my own Web page [threeseas.net]
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
What other dev models are out there? (Score:1)
I really prefer to participate in a project which is open sourced rather than closed sourced.
However, I'd like to know if you fellas know about other dev models that could be better in certain circumstances. Or is it just Open Source vs. Closed Source?
Re:Unfortunately... (Score:5, Interesting)
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.
Re:Unfortunately... (Score:1)
Comment removed (Score:4, Insightful)
Re:Hmmm.. (Score:2)
Forgot one (Score:5, Insightful)
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.
Re:Hmmm.. (Score:5, Insightful)
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.
Re:Hmmm.. (Score:1)
Re:Hmmm.. (Score:2)
Obviously, you've never taken an introductory programming class, or you would know that the answer to that question is, "About fifty more, due next Thursday. And would you twerps please stop using one letter variable names?"
It's interesting that, in my opinion at least, the ratio you cite is about the ratio I've noticed in the closed-source community. I don't think that open/closed source has much to do with
Re:Hmmm.. (Score:2)
Originally, Open Source was being practiced primarily by the pure computer science folks, but the idea is slowly percolating down to the more mainstream developers. If it gains mindshare, it means more support for a lot of different interests, such as business management or--as y
Faster? (Score:3, Interesting)
Linux, Wine, gcc, Mozilla. They all took, or are taking, a very long time to develop.
Re:Faster? (Score:5, Insightful)
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.
Re:Faster? (Score:2)
Re:Faster? (Score:1)
I suppose that is one of the catch-22's in the open source world: if you get developers to volunteer their time and work for free then you have to tolerate the long delays in project completion and updates. But, you get a better finished product -- assuming you have decent programmers working on it -- because the programmers are personally involved with it and have a personal stake in the finished product. OTOH, if you PAY
I Suspect It's Like Sex (Score:4, Funny)
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.
There are some reasons for formal processes... (Score:5, Interesting)
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).
Re:There are some reasons for formal processes... (Score:2)
I don't subscribe to XP in everything it says, however a close r
Re:There are some reasons for formal processes... (Score:1)
So what do you do when they don't sign it? They'll obviously know what you're trying to do and see the handcuffs coming. I've never gotten anyone with any kind of power to give it up that easily.
The Cathedral and the Bazaar (Score:3, Informative)
Re:The Cathedral and the Bazaar (Score:1)
Thank you... (Score:1, Interesting)
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...
A proper comparison? (Score:3, Insightful)
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.
Re:A proper comparison? (Score:2)
Actually, these sorts of things pop up really quickly with the open source approach since everyone and their brother has their browser set up with different plugins, etc. I just came accross some interesting bugs in the OS CMS I develope at work when trying to look up info in it from lynx when I installed bad video card drivers. We weren't designing it to work with text browsers, but it does now thanks to t
different motivation (Score:2)
The limits of open source... (Score:2)
Sure there are scenarios where open source i
You know a study is bogus when... (Score:1)
Open source has some usefulness, but it doesn't need a bunch of twerps from a lame college to advocate for it, presumably while being paid by some corporation that can't outsource fast enough. The limited benefits of open source are evident enough.
In other news... (Score:1)
better programmers? (Score:1)
1) you contribute only if you know you are good because if you are not your part will be thrown away with no benefit for you and for the community (self selection)
2) in general open source contributors are more proactive than average developers and more open minded
3) motivation, motivation, motivation: your pride is involved
Also, more
We want proof? (Score:1)
The ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing. More importantly, OSS evangelization scales with the size of the Internet much faster than our own evangelization efforts appear to scale. -Microsoft, Microsoft Halloween Doc 1 [opensource.org]
No Mystery on Open Source (Score:3, Interesting)
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.
Engineering vs. Authoring... (Score:1)
Re:My Experience With Open Source (Score:2, Funny)
hehehehe
Clearly your post was meant to insight a flamewar but I think it's just funny. Thanks for the laugh.
Tom
Re:My Experience With Open Source (Score:1)
Link [zone-h.com]
Link [betanews.com]
Link [lichtsnel.nl]
It's cut and paste.
Re:My Experience With Open Source (Score:2, Interesting)
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.
Re:My Experience With Open Source (Score:3, Insightful)
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 server
Re:My Experience With Open Source (Score:3, Insightful)
I have mod points myself right now, but how do you mod a post as completely clueless? I could have wasted a mod point on "overrated" but somebody would have just modded it up again.
The parent post was a JOKE!!!!! How could anyone but a PHB read it and not realize it was a joke?
Re:My Experience With Open Source (Score:2)
Re:My Experience With Open Source (Score:2)
Re:My Experience With Open Source (Score:2, Informative)
Re:My Experience With Open Source (Score:1)
Re:My Experience With Open Source (Score:4, Insightful)
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?
Re:My Experience With Open Source (Score:2)
Oh brother. I'm so fucking sick of hearing this. I agree with you that dude's a moron about Linux, but don't play the "You must work for Microsoft" card. It's sort of like comparing somebody to Hitler, only not as bad.
Re:My Experience With Open Source (Score:2)
Re:How to crash linux. (Score:3, Informative)
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 ha
Re:How to crash linux. (Score:4, Informative)
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.
Re:How to crash linux. (Score:4, Informative)
Re:How to crash linux. (Score:1)
Re:"Cheaper" is good (Score:1)
Where are engineers working for "mega-corporations" for free? Last I checked, people who worked for big companies are payed -- and often payed well -- for their work be it in the closed source world or open source world.
If you're talking about people writing software and giving it away under the GPL thereby allowing companies to exploit their work for profit well, that's a different story. But I still don't think the
Re:"Cheaper" is good (Score:1)
Of couse I am modded as a troll, since I didn't toe the party line that "free software" is good for us.
Re:Gnome problems (Score:2, Informative)
Unlike KDE, Gnome is free Translation : GPL is freerer than LGPL. LGPL allows corporations...
I think you got GPL and LGPL reversed. Also since novell has taken over ximian they have released many peices of code under Open Source licences, and provided many coders to gnome/mono causes.
As for fonts. it may be patent infringin