Does Open Source Separate Business From Technology?
hornerj asks: "I've noticed quite a few pundits commenting on how the Open Source movement goes against the standard business model. I've come to believe that it not only goes against it, it rewrites it. Could it be possible that, with the shift from marketing software to marketing services, the business suits are being forced out of the technology pipeline? If IT businesses shift to providing services, will the suits, which historically make software releases buggy, bloated, and premature, be taken out of the decision process? Without a suit forcing an unready software release, it only makes sense that software will get better and better."
In the Middle Ages in societies with limited literacy, high cost of information distribution and overwhelming politically-backed power of religion science was in the situation, similar to what commercial software is now -- consisted of "secrets" (like modern secret algorithms), obscure terminology (like modern secret data formats) pieces of religious texts and ancient books, quoted everywhere, distorted and taken out of context (like modern botched and mutilated standards and marketing buzzwords), religious "laws" severely restricted what can be done (like modern patent and copyright laws), and were vague enough to support arbitrary witch hunts against anyone (like modern frivolous lawsuits). This allowed "scientists" to produce huge amount of "work" that has little or no relation to reality, and people who practiced activities that required scientific knowledge either did their job poorly because of lack of one (engineering, like modern AI), used huge amount of resources for nothing (architecture, like modern bloatware) or turned their work into complete quackery (medicine, like most of areas of software design now).
Improvements in the information dissemination technology and weakening of the grip of religion over society caused science to become more open, and openness with wide peer review allowed scientific methods (that were known long ago yet were ignored in the absence of openness -- this is why it was called "renaissance" and was percieved by people as return to earlier, better ways of science, engineering and art) to weed out the bullshit and keep the true achievements, hidden under piles and piles of "mental masturbation". The use of this open science in various kinds of trades/businesses improved, so the job of scientist switched from "secret lab" of what amounted of skilled craftsman or "library" of religious philosopher to education institutions (that also sponsored research and books publishing) and "service" work for large engineering projects. Secrecy remained only in military-related projects, and those never amounted to much before being opened or reproduced.
As the result the progress in science went on with reasonable pace, results became openly accessible and reliable (as scientists had to make them possible to reproduce), quackery was reduced to fringes of society (some modern societies have large fringes, however this is a different problem).
When software design, the area that has properties of both theoretical science (practiced by scientists) and engineering (handled mostly by businesses) appeared, more appropriate science-like model of development was very soon replaced by business-driven model of secrets, commonly used for engineering, and it ended up at the same place where science was many centuries ago. And the same processes that opened science will open the software design/development -- the key ingredients such as widely accessible education in the area, means of dissemination of information and large amount of freely-distributed information are there.
Contrary to the popular belief, there indeed is no God.
While I work in a closed source shop, we are service based. We may sell our products for millions of dollars, but the real money is in the services.
Our customers have to work 24x7. They are not really satisfied with 99.99% reliability (You can figgure it out for yourself, but that only allows about 2 minutes of downtime in a year - way to much) Management has learned that with these customers you demand 100% relability. We have suits. They only stop harping on relability after several rounds of testing, and then only if all known problems are just minor. That is they know the process of fixing bugs often introduces new ones, which could be worse then the old one.
Suits will have to change as they realise that servies makes the most money when the department is filled with only bill collectors, and the least when the department is flying from customer to customer on technical problems. So by expending more effort upfront they save money in the long run.
More releases don't necessarily mean better releases...
One problem I do see is that there is an assumption that the Suits have nothing to contribute, that they're a faceless mass of oppressors. In the department I work in, our manager, a "Suit", keeps connected to the market and has saved our backsides several times because he knows what's going on.
If there are two things needed it is:
1) That business and coding respect each others spheres of knowledge and decisions.
2) Suits learn more about programmer and programmers learn more about business.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
With all due respect, the idea that "the Suits" are the cause of all software/IT problems is, at best, a half-truth. Yes, there are stupid deadlines, bad budgeting, and more - I've been there.
But as a programmer I've also seen coders and developers screw up projects as well. I've seen people assign underskilled programmers to vital projects so they can do "fun" things. I've worked with coders who have no sense of design or deadline or responsibility shaft customers and employers.
Open Source is definitely going to require a rethinking and rearrangement of current business structures, and I think it will be for the better. A service (ie results) approach is definitely needed in IT. Just don't expect an overnight cure, though it's my hope that the service approach will work its way to all levels of IT.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
To hornerj:
Just because OSS moves into the enterprises doesnt mean business people are replaced. Contrary to popular opinion, other people with different skills must be used inside the business to make it work. When is the last time someone audited the books for their company and it wasn't their job or they owned the company. *Wind blows, tumbleweed blows by*
To all:
I have seen this argument about OSS converting companies into service-driven enterprises and getting rid of software products all together. I think this is a fruitless cause. Yes, some organizations may make it by selling support and services, but most will not. Here is why:
First and most important, good people are tough to find and even more expensive to hire and retain. If your trying to hire both support/consulting personnel and programmers, your doubling your workforce when only half of your workforce, the support/consulting personnel, is contributing to your bottom line.
I will concede this feature at the enterprise-level has been one that's paid for, but I will address that in a minute. Support/consulting for general consumer applications will never be a large money-maker and the product must be sold. Their is simply no way a company will keep itself in the black selling support for an email application.
Ahhh, the channel. It was your friend for a number of years picking up where you left off by integrating applications and providing support, while getting closer to your customers. Now you won't to horn on there turf? Even if the company and application are new, the channel will go after it. Why? Because their is money to be made there. Your moving into territory where you have few friends and three strikes against you, no customers, a stronger competitor, and its not your core business.
Kinda same with the channel. If your building applications, your core business is not service-based. Trying to run outside of your core-business is not impossible (look at IBM Global Services), but its much more difficult.
Will the OSS and service-based business model work. Well it hasn't yet but that doesn't mean it won't though. Support/consulting has been a small money-maker for some traditional product selling software companies. However, those companies had two advantages, they knew the source code and it was a sideline business. None of the Linux crowd has turned profits yet and business models are not yet fully developed.
Who here has bought support as a consumer and not for or as a business? Not too many I would imagine. In the case of Linux applications and distros, its tough to support a business model when you eliminate 40% of your customers because either they're smart enough to figure out or can find the answers easily.
/me gets off his soapbox
Hangtime
"If you continue to think the way you have always thought, you will continue to get what you have always got." - Anonymous
>How many patches, service packs, etc do you have
>to apply to WinNT4 server and IIS4 before they
>are secure enough to use?
Exactly, in a sane world we would have had NT 4.1, NT 4.2, etc instead of downloading 80MB+ service packs.
A lot of stuff changed with those service packs, it would have been worth spending $$$ on NT 4.1 just to get documentation that was up to date.
As a programmer, my natural inclination is to reject management forces. But I have come to the inescapable conclusion that software development is a process that must be managed, on some level, as an organized task.
The current systems and processes for software development are revolting, but that doesn't change the need for organization. Existing processes are modelled on old engineering practices and driven by corporate machines. Open Source development is changing the underlying models, and we can expect processes to follow suit as the effectiveness of OS organizational models gains recognition.
The important thing is to continue developing and practicing those new organizational models, and to continue pointing out those models which bear fruit. The Linux kernel and the Apache Web server stand as monuments to efficiency and quality, and they are destined to be among the forefathers of whatever processes we use in the next decade.
I just hope that we don't reject corporate development models by rejecting the entire notion of organizational intelligence. Next-generation management models would be a giant step forward for software development; management-annihilation would be a step backward.
MJP
Don't try that "protecting the children" shit you people use to keep the tits and bad words off my TV. --Seanbaby
And if only we could all "just get along" we'd have no more war and all our tummies would be full.
/. server report: The front page says I'm logged in, but the story and reply pages say I'm not.
Reality Check: If there is money to be made, there will be scam artists. This is a fact and no amount of putting programmers on pedestals and demonizing business people will change it.
Take, for instance, RedHat. They are a company in the "new model". Do they have non-programmers working there? Yes. Do they ever release buggy software? Yes. Well, there goes that argument.
This is not to say that OS software is "as bad as" the other kind--but it is to say "OS is no panacea".
A much bigger revolution (IMHO) is the sudden restoration of freedom that OS (or FS [Free Software]) brings. Suddenly we can share software! We can modify our own software! The pool of talent expands by orders of magnitude once you can include people who can't code but CAN document, bug report and test.
BTW, new
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Software isn't made in a vacuum, it's made to fill some need. In the case of free OS's like GNU/Linux it was created to fill the needs/wants of the people who put it together. In the case of a system for verifying bank deposits made at an ATM (I work at a bank) it is created to fill the need of a suit. So the impetous and the requirements don't come from the programmer but from the suit who happens to be the end user.
Outside the internal software situation impetous and requirements still often come from suits. Take wordprocessors: while many text editors have been created by open source methods they don't match some of the features of commercial packages - and if they do the features appeared in commercial packages first. The requirements of the suits caused the programmers to go beyond what they themselves needed or wanted.
And when you have a suit funding a project they will - with good reason - want a timeline and project deliverables. While the timing may often be unrealistic, the concept is reasonable.
IMHO, as per.
J
Oh well, no point in steering now.
Without a suit
forcing an unready software release, it only makes sense that software will get better and better."
Would that it were so!
I think OSS will make software get better, but not for the reason you suggest.
The problem isn't the suits -- it that the economic incentives in a pure proprietary software market are screwed up. Remember James Fallows' article on his brief consultant stint at Microsoft? The engineers make the decisions about what goes into the product, based on the need to maximize their stock options' value.
The problem with all the classical economics-ish arguments that favor proprietary software is that they assume that software is a commodity, that consumers have fairly good information, and freedom to instantly redirect their purchases. These assumptions work well for simple commodities such as sausages. Sausage company A introduces a secret spice to their product. Sausage company B figures out how to produce their sausages cheaper. The consumers then simply decides whether they want a spicier, more expensive sausage or a cheaper, blander one.
Software presents several unique problems. First, it is hard to measure software -- it is uniquely complex among all products and cannot be quickly easily evaluated. How many times have you paid for an "upgrade" that made things worse? Sometimes less is more. Because of this people are poorly informed and rely on what the read in the press, and that is at best a very shallow kind of analysis, that over emphasizes features. That's how we get bloat.
Secondly, current and future software purchases are tied to past purchases. You don't have to retrain all the consumers of Sausage A on how to eat Sausage B, or have to interface them.
This tying goes backwards in time as well. Because software producers can withhold old versions of their software (which users may be perfectly happy with), they can force users to upgrade to maintain internal compatibility with changed file formats and procedures. When sausage company A introduces their new spicy sausage, they can't make you pay to upgrade all your old sausages with a spice pack upgrade.
Proprietary software development has an unique incentive to produce new, more complicated and incompatible products, despite the fact this is manifestly against the consumers' interests. The difficulty of switching also means that they have almost no incentive to maintain the things you like about old versions of the software.
This is why software is so horrible. If the economic incentives were to create good software, the suits would find a way to do it.
Free software (that is software which users are free to modify and redistribute) has none of these perverse incentives. People develop free software to scratch an itch, either personal or for their company -- the production incentive is precisely matched to the need. If you view software as a purely a commodity, rather than a solution to a problem, then in theory free software would lead to an underproduction of software. Clearly this way of thinking about software is incorrect, because there is an abundance of useful and important Free software and it is a rapidly growing field.
However I don't see proprietary software being overtaken by a free software monoculture. I forsee an equilibrium being reached, in which free software forces proprietary software to be better attuned to consumer needs. The equillibrium point will be different for every kind of software, and will depend on a mixture of factors:
(1) How far down free software can force the price of proprietary software.
(2) How much marginal value can be added by the capital attracted by exclusive profits of proprietary software.
(3) The supply of programmers for consulting work and for free software development. Naturally this depends on how interesting the problem is.
(4) The willingness of consumers to cooperate with each other.
I suspect that proprietary software will remain the norm in vertical market type applications, because of the difficulty of cooperating exclusively with direct competitors.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
It's not that developers don't care about UI issues. It's that what a developer thinks is a usable UI differs wildly from what an end user would think as a usable UI.
Personally I'm comfortable with command lines. And honstly if I'm going to use a UI for building code, I wouldn't mind having a "Compile and Debug" menu item which essentially forks make from within the editor, or which forks a batch file that runs a bunch of other programs. Furthermore, I have no problems with dealing with 'ps' and 'ls' and 'fgrep' and other such utilities.
Yet I write software for the Macintosh: command lines for end users is not an option. Expecting my end-users to use a computer the same way I do is sort of like expecting an 18-year old auto driver to fly a 747: yes, it's basically about moving a vehicle from one point to another. But operating a 747 is nothing like driving a car.
Most developers I know don't have the touch of graphics design experience combined with an appreciation of the finer points of UI design to make a really effective user interface without some feedback from a good UI designer, or at least without some pressure from a suit to improve the interface. Most of us have too much experience fiddling with the knobs and dials of the 747, and while it's nice to be able to control which fuel tank the left engine pulls fuel from, most end-users just want to go from point A to point B in some style, and would rather us concentrate on getting the color of the exterior paint the right shade of racing green instead of improving the knob placement of the autopilot controls...
If you use Apache you don't have to release your entire project under the Apache license. If you use Linux you don't have to release under the Linux license. If you modify or extend them as software tools you do. Most projects USE these tools, they do not modify or extend.
An Eye for an Eye will make the whole world blind - Gandhi
Do I feel like John O'Gaunt railing against the tide of change.
Nope. OSS doesn't rewrite the business model it mearly changes part of it. OSS has proved itself to be a wonderful tool the way of developing.... well tools. But most business/software decisions are about updating or creating systems. An area in which OSS has little or no experience and impact.
Take the following example
Company A have received $2 million in first round funding, they have to build a website and get it running in 5 months to ensure 2nd round funding.
Now how does OSS get them to their goal ? They need an intelligent searching agent that works on fungii, for this is fungalinfection.com, this has a lot of spiffy features and is the unique feature of the site. So they approach a company who USES OSS tools, like Apache, maybe Enhydra and a big old commercial database like DB2 for there are many transactional and critical pieces that go into breeding your own fungal infection online.
This is old style but using the tools of OSS.
The examples are endless. If someone can show me why OSS changes this model I'd like to know. Taking the example above. Lets say that fungalinfection.com release ALL of their code. And here comes fungalbreeder.com within a week.
Not enough to convince you that there are many different parts to the software industry ? Okay here is another...
Company A has a legacy system that they want to replace in stages, first to be replaced are the screens with spiffy Java clients. Next up is part of the product catalogue, next up is the ordering process, then comes their warehousing system, and on and on.
These will probably use many OSS or other "free" software products but the final piece of software will have been created closed source. There is the argument that then releasing it would open it to the world and thus mean 10,000 people fixing bugs.
Rubbish. The only people who would care would be competitors, why would 10,000 people look at a warehousing system. There are enough 1 or 2 people projects out there to prove that its mostly the "sexy" ones that get done.
I appreciate OSS, I use OSS, I've even submitted patches to OSS and FSF but while it may make me a Luddite I don't see how anyone is going to build bespoke systems using OSS.
Lets put it this way, it takes 10+ years and 000s of developers to build an Air Traffic Control System, do you think this would work well in the bazzare enviroment ?
An Eye for an Eye will make the whole world blind - Gandhi
Once a product is feature-complete, all that's left is bug hunting. If the bug list is driving the coding effort, the Whole World (tm) gets to see it, gets to knock things off it, gets to verify for itself whether and how bugs have been eliminated.
The only thing that's to a company's disadvantage is that it's harder to make money supporting a high-quality product than by patching up the bugs and selling the fixes as an "upgrade." Nevertheless, the old model is disappearing. Just as Detroit had to abandon planned vehicle obsolescence in the face of high-quality, reliable imports, closed-source companies are being forced to meet the challenge of open, provable-quality software. Some of them will do this by lobbying for absurd laws (see George Will's May 15 Newsweek column for a fascinating mundane example). Some will do this by suing us. The ones that survive, though, are the ones that prove they can adapt. They always are.
--
This is not my sandwich.
"Could it be possible that, with the shift from marketing software to marketing services, the business suits are being forced out of the technology pipeline?"
I question that this business model is much different than those of some of the most successful computer companies. Granted some do not fit that model, but many already do so in one way or another. Take IBM for an example. Yes they market the software, and the hardware. IBM's big $ comes from the services they sell afterward. They may be consulting, programming, or even maintenance. IBM has strategically positioned it's self so that it's service is needed by most of it's customers (more $). Granted some people consider this unfair, but it's a huge cash cow (moo) for them. I should also note that they have plenty of "suits" still.
Outside of my IBM example, I have trouble seeing how much different the world would be if OSS dominated and the "suits" were all but gone. Granted I'm sure "suits" do some stupid stuff. However I'm not convinced that IT Business would be better with programmers or those providing the service running the show.
I'm also not convinced that the "suits" are the only ones responsible for making software buggy, bloated and premature. I know of several game companies that are run by their game programmers and designers realized total crap because they were low on $, or felt they had to release when they promised. I would use Maxis as an example. Just because a "suit" says "release now!" and the program isn't ready, doesn't mean that other non-suits would do any different or better.
Sure, sometimes it is easier to have a direct connection, but unless you have better "suit qualities" then the actual manager, it gets very hard to get any "real" work done while talking to every damn user there is.
A good software manufactorer has good suits *and* good coders *and* a good connection in between. Of course the connection is optimal if there are hackers inside the suits, managers behind the keyboards (or even the same people in both roles) but unless you are real renaissance wonders, you have traded better communication for worse managing and/or coding.
I am a developer, I love good managers on my projects. They simply makes my life so much easier.
All opinions are my own - until criticized
Nobody buys a program that does not work (at least not twice) Bells and whistles are what sales people use to get more money out of the same product, or make ppl buy *their* product instead of an alternative with the same functionality, but less appeal.
Yes, from a hacker perspective, it would be nice if people bought software simply on its technical merit. Wake up call: they don't.
A good coder makes the life of a suit easier, a good suit makes the life of a coder easier. A damn good salesman can work with inferior products (if he has to) and a damn good coder can override bad management.
In *my* HO a good salesman sees a demand and amplifies it. Creating one out of thin air is too damn hard (if at all possible).
All opinions are my own - until criticized
Good programmers makes really good apps, good suits get those apps sold and are good at seeing what what services (and apps) people are willing to pay for.
Some people are good at both.
You won't make it very far with exellent code without marketing. Neither with exellent marketing of lousy software. (No M$ does not make lousy software. It is not the *best* but for most people it is good *enough*)
Suits follow demand. If they are leaving your area it is a tell tale sign that you will have serious trouble making a living there in a near future.
(That does not mean you should stop coding, just that you'll need a day job)
All opinions are my own - until criticized
I think I need to remind people that while open source is incredible at some things, like networking software, it is awful at others. Open source works well where software engineering is more service driven because this scratches itches. It is in the best interest of everyone to improve their tools, even between competitors. OS is abysmally bad at other things, like games, because they don't have the same itch-scratching effect (plus games today are more about art than code). It is also almost impossible to create a totally trusted client using purely OS technology, this is very important for some applications like games.
So far I've gotten all my Karma from telling people they are wrong... :)
Free Software (or the bastardized Open Source version) is about freedom. You have the right to modify or copy software that you have purchased.
RMS used to sell emacs tapes.
Redhat sells distributions with Linux, GNU, and other software.
VA Linux sells systems using Linux.
Under the GPL, you are NOT entitled to a free copy. The idea is that if you get a copy, you can do what you want.
Free Software is BEST suited to these sort of custom solutions, it is LEAST suited for general purpose applications. The fact that it has produced the general purpose applications is a fortunate result, but is odd.
Why is this?
If I need a custom solution, I need to pay for it. Either I hire a bunch of coders who right it, or I hire a consulting group to produce it.
It is CLEARLY in my interests to get the code and the right to do with it as I please.
If I want an air traffic system that will cost $100 million dollars over 5 years, I had better be asking for the included source code, right?
That's all that open source requires. If I pay the development costs, I don't want a copy that I can license, I want the work produced.
If I copy it to all my servers, or publish it on my web site asking for feedback, that is MY right.
The systems created are AUTOMATICALLY open source, as I have a copy of the binary and also have a copy of the source.
If I write a general purpose application, it is most likely to succeed in the proprietary form.
Why? Take an Office platform. The cost/copy is VERY low, because the development costs is spread over millions of users. With custom solutions, there is only one user, so they can pay the entire development costs, and they will INSIST on the right to modify and reuse their copy.
They won't give it to competitors, but the creator of the code may try to sell their services to competitors. That is the service model of open source.
Open Source does NOT mean that millions of eyes look at it. Linux, GNU, Apache, Mozilla, etc., utilize the bazarre model.
Why? Because they are creating a product that is too difficult to produce as an individual project. Torvalds could NOT have single handedly written a kernel to compete with SCO, but he wrote one for his own use. He made it open, and other people played around with it. It eventually became competitive with existing products, but only because millions of people kicked in a little work.
The bazarre model kicks in in general purpose applications when authors know that they can't make the product cost competitive with entrenched software, so they solicit wide ranging help.
Open Source doesn't mean free as in beer. You may still have to buy the copy, but you can then distribute it. For general purpose applications, the cost to buy would be low, so you would buy to redistribute... hence the bazarre/free development.
For custom applications, you spend a lot on something only valuable to one person/entity, so they'll pay a lot of money to develop it, but insist of the rights to use it as they please.
Stop confusing the bazarre model with open source.
They are independent events that happen to overlap.
Alex
Running a business consultancy is not just about technical knowledge. One has to have a customer base to draw from. The hard-core techies cannot and would not dress up as salesman and look for clients. So either you get yourself a suit, or you become a suit.
No - suits doesn't mean black boots, black cape, dark helmet and mean, breathy voice.
- There is a single business modelwhich will be rewritten and that cant accomodate change.
- suitsdo nothing in an organization except stand around imposing bloatware and quick releases on poor developers?
Should the management and support staff listen to the developers in an IT company? Yes. Are they the only people who should be listened to? No. Successful products are created by an integration of efforts and every other discipline involved in that company (usability expert, marketing guy, account manager, accountant, sales dude) is *necessarily* part of that process regardless of business model.Besides, in my company the suit who causes the most problems goes under the title customer. And him Id find it hard to get rid of.
Because the snark was a...
True, look at Gnome, KDE and the 100 other "easy to use" windows managers. Most of these windows managers had little or no suits involved in the process of creating them. But remarkly, they are simple to use, look good, and have good qualities (has ANY EVERY had a non-alpha windows manager crash on them?)
But without the "suits" involved, the developers/coders know that they should "hard code" their windows manager into X and know that X shouldn't be hard coded into the (linux, *bsd, other) kernel.
IceWM looks just like Windows95, but you know what, IceWM is FAST and there is no way IceWM can crash the entire OS
IceWM is also very easy to use and could target a large number of users, for example I am willing to bet that it would take an average user 5 minutes or less to learn IceWM if they are famlair with the windows shell
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
Surely code monkeys should be writing code, not running the show? I would prefer a great programmer spent his working time improving the code, rather than running a business. I don't really see how Open Source alters the business model that much - companies sell services rather than systems - well, that's not exactly a world shattering event, theres been plenty of service industry work for years now outside the IT world (even within it!).
I think it kind of does because bugs get fixed quicker so they can be incorporated in the next release. How many patches, service packs, etc do you have to apply to WinNT4 server and IIS4 before they are secure enough to use?
Thats a comment with no grounds in reality.
For a start I could not afford UNIX in 1989 and Linux is free.
The main thing open source has done is to show how quick a release cycle can be. Compare the number of Linux releases in the last 5 years to the number of Windows, OS/2 or any other commercial OS.
The suits will get left out of the loop because thay slow things down. If they have any sense they will step back and let their code monkeys run the show.
Developing commercial software for Linux is pretty much the same as developing commercial software for Windoze. Does Word Perfect work any better on Linux than it does on Windoze? Not that I've seen.
The strength of Open Source is in things that are outside of the core business area. If your company needs a program to frob wampuses, and frobbing wampuses is not part of your core business, they'll put a couple of programmers on it. The way these things work, they'll come up with a clunky, limited program that does the job strictly as specified.
Fine. Now what do you do with it? In the "conventional" business model, the suits clutch it to their collective breasts and cackle "Mine!! All Mine!!!" like a miser in a bad movie. The software sits there and festers. It can't be sold (it's outside of the core business, remember) and the programmers move on to other things. Bit rot sets in.
However, suppose the company releases it as open source. Now, anybody else that wants to frob wampuses can grab a copy and hack on it. One guy needs a better user interface. Another needs to handle other types of wampuses. Yet another wants an interface in Turkish. Now, you've got a classic Open Source project, a la tC&tB , and all you have to do is ride it. Your programmers get recognition in the Open Source community and you get a better program, all for less than you'd probably spend on maintenence of the original.
Trying this in a core business area is a recipe for disaster. Mozilla is *how* late now? Why should Joe Programmer spend his spare time hacking your software just so that *you* can make money off of it?
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Presumably this means that customers for software projects will look over their wire-rimmed glasses, see that the person talking to them is wearing a sweat-stained Quake t-shirt rather than an Armani and suddenly be overcome with the milk of human kindness. No, no, dear boy, they will say, take all the time in the world over your project. Make sure it meets your full artistic vision. Take it easy. Play some QUake. Don't worry your head about that silly "penalty clause" -- we put that in when we were dealing with suits. Now that we know that the code-monkeys are in charge, we're happy to sit here with fifty container loads of oranges in an unrefrigerated warehouse, waiting for you to write our ordering system.
Bankers, too, will be infected with this Open Source Flower Child ethos. Hey, man, they will say, it's OK, man. Take a toke on this. Your software isn't ready yet? Because you were playing Quake? That's coooool, man. We'll just extend your loan facility by another month. We're not breadheads here .....
Software is rushed because bills need to be paid, and people cannot, typically, be convinced to part with cash unless something is delivered to them. That "something", so far in history, cannot be a sweaty Quake player's promise.
Bills will need to be paid on time, for the forseeable future. People are unlikely ever to provide the wherewithal to pay them without being given software. Therefore, from time to time, software will be rushed, and developed badly because of it.
-- the most controversial site on the Web