Slashdot Mirror
How to Misunderstand Open Source
Sam Hiser writes "This article intends to clear up some misconceptions about open source software development practices. It can help developers, IT and business managers transition from a closed development environment to an open one characterized by shorter time-to-market and lower costs. The author, Tom Adelstein -- an experienced CPA, code developer, project manager and consultant -- makes clear the notion that Open Source Software bears a mark of professionalism."
See also ESR's Prudential Interview.
Belief is the currency of delusion.
That is nonsense.
First of all, open source software doesn't have to be non-commercial. For details, see the Free Software Business Strategy Guide.
However it is true that many open source projects are non-commercial in nature. The resulting software is still quite often suitable for business use.
From an economics perspective, each proprietary software program is a monopoly - only one company is able to fix problems and release new versions. Monopolies are good only for the company holding the monopoly, not for everyone else.
Therefore, if proprietary software goes out of fashion, this will be bad for precisely those businesses whose main stream of revenue is from software licensing. This will however be good news for all other companies.
Whether this will mean less or more jobs for programmers is hard to say in advance. There will be fewer jobs at specialized software companies and there will be more jobs at companies which use software, since it'll make sense for companies which use software to have relevant expertise in-house.
I work in a lab of 23 people for a government contractor. The author's description of a closed source envirnoment is VERY much like ours.
... add another step to the process. [rant mode elevating] Only half our lab are actually developers - 1 mgr, 4 sys admin types, 3 leads, and 2 process nazis. I've seen my coding time over the last 3 years go from around 50% to about 25% due to process "improvements". The rest of my time is spent in meetings, reviews, and documentation. You want that bug fixed? Well, you're looking at a month turnaround minimum. Yeah, it was a one-liner or two-liner, but we've got to cost the anomaly report, potential revisions and reviews for the requirements doc, the design doc, hand code over to CM, wait a week for them to build it and admin to configure, retest (sorry, that's full testing, we don't trust regression), test report, and acceptance meeting - each meeting has a three-day lead in which the documents must be released for review prior to the meeting. Any action items must be completed prior to moving to the next step in the process. Oh yeah, don't forget to do the paperwork associated with the original anomaly report...gotta get concurrence from the originator that your fix is legitimate. Oh, they're on vacation? Ok, hunt someone else down, explain the problem, show how to duplicate it, and if you're lucky they'll give you a thumbs up. Otherwise, give them time to look at it... Gotta get that CMM level 3, ya know.
The name of the game here is process. Don't get me wrong, process is good, but when it gets in the way of logical decision making, process is bad. And management's knee-jerk reaction any time there's a problem
When's 5:00?
Sure it can. I've seen more than one company running Coldfusion MX on a Linux box w/Apache. I've also seen a company running JounryX (Timesheet management SW) on top of Postgres/Apache on Linux. To say that it can't be done is nonsense. Whether your company should combine the two is another matter.
If this is a troll, I apologise for my naivete. Anyway, here are your answers:
1) The article suggests that open source methods are useful even in a closed environment. You're right; If the code isn't available then it isn't open source.
2) 'License alignment' can be a problem. The premise is that you only get to play the open source game if you play by the rules; If you want to use the products of others' hard work, you have to make your own code available. Projects which rely on closed binaries can't use code licensed under the (restrictive) GPL at all, but may be able to use code with less restrictive licenses (like the Lesser GPL.)
3) Plenty of companies make money from open source code, they just don't make it from keeping code secret. Usually the money is to be made by adding convenience (shrink-wrapped software with a nice installation routine, say) or services (such as support.) Of course, they don't have the same development costs as companies which are closed, as they can build on the work of others rather than starting from scratch.
4) Most programmers (AFAIK) work for companies where the end product isn't software. They are in-house programmers developing internal systems, or the company uses software to sell hardware, or the company uses software to sell support. Companies which go open-source will surely have a business plan which will take into account the loss of revenue in software sales. The money is to be made elsewhere.