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?
I would have to disagree with you. An experienced Linux admin is able to install the common stuff (such as apache, mysql, etc) easily, and it is pretty straight forward. Furthermore, news groups provide tons more help for any given opensource application. To state an example, I know first hand that installing and getting QMail to work properly is much more intuitive than trying to install and configure Exchange with all its hundreds of configureation options hidden everywhere.
If you are finding that supporting a linux box takes more work than a windows box, then it may be because your admin is not too familiar with Linux. Here once a linux box is up and running, we rarely ever touch them again outside of checking logs to make sure everything is running smoothly. I don't want to even begin to calculate how much its cost in manhours to support our numerous windows boxes for just the patching of secuirty issues alone.
ah, the beauty of slashdot, where people who don't understand economics talk about it anyways.
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.
It's not about monopolies at all, unless a company is FORCED to choose a specific product/service. Companies know and take into account all costs of software, including how much support is going to cost. It's not about being locked into a specific company, it's about choosing the product which best fits.
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.
The One KEA wrote:
The Linux kernel is widely and highly regarded, and stories of Linux systems running without crash or reboot for 6 months, a year, even more, are common.
Mozilla? I turned to it when eBay dicked with their formats and brain-dead MSIE refused to save as HTML. Mozilla was able to save such pages (hey, if the browser can render the page, how can it claim not to be able to save the components it used to render it??), but only once. On the second save it would invariably crash. I had to close it and relaunch it for each save.
Those others I haven't used. I have done several Linux installs on very standard IBM brand PCs that failed to identify the graphic chipset and ended up giving me critical windows with both top and bottom off the screen. I also found the pop-up bar at the bottom amusing, because by default it came up behind open windows.
The nested dependency thing is something I had the displeasure to experience recently, trying to install SpamAssassin on an AIX system. It required several other things. I used CPAN, which was amazing and frightening -- amazing because I hadn't realized that so much work had been done to automate such things, and frightening because I had no idea what all it was installing on my system. It eventually crapped out several levels down, and the whole install failed, leaving God only knows what incomplete garbage lying around.
Some months ago I walked in on a friend who was straining over an IBM Intellistation and the O'Reilly Linux book complete with CD. The network stuff wouldn't configure following the explicit examples given in the book. Several days later, after countless hours on the Internet, he dug out the correct information from some obscure corner of the Net.
Sendmail was obviously written by malicious alien visitors. Try configuring it without using the shorthand m4 macros. IBM distributed sendmail in AIX 4.3.3 with sample m4 files and instructions, but not the m4 macro processor. I finally found one but couldn't get it to work according to examples in the sendmail documentation. Then I looked for sample sendmail configs on the Internet, and ran into one of those "What's wrong with this picture?" things -- there weren't any.
The Apache Web server distributed by IBM in AIX 4.3.3 conveniently has its "deny" by IP address feature completely broken. There's no question that Apache is a kickass piece of software, but jeez, a significant feature completely nonfunctional...
Being a serious hater of vi (which was obviously first written by someone who had never seen an editor UI before), I installed the Joe editor. It promptly destroyed the standard vt100 terminfo or termcap file used by the major app I run and still can't run right without its own special termcap in the user's home directory.
Have you ever seen the matrix of Linux drivers for Adaptec SCSI HBAs? It's a nightmare of a bad joke. There's a different driver for just about every combination of Linux point version and Adaptec card model. One guy has pretty much had to devote his life to just that one little corner of Linux. That's sick.
I follow the rs6kpreplinux list, where one person on the entire planet has done the work to provide for running Linux on RS/6000 43P 7043-140 machines. I still haven't tried the stuff because I'm waiting for the list to stop carrying mostly "I tried xxx and it didn't work" messages. "Oh," says the author, "Maybe I forgot to include the zzzz module in the kernel patches, let me go check..."
Virtually every Microsoft product on the shelves of stores in shrinkwrap is broken out of the box, requiring hours of downloading "service packs" and other doo-dads that are sometimes nearly impossible to find.
Look at the bright side: there's always seppuku.
It always surprises me when people equate the GPL with releasing the code to the public. I won't say that I completely understand the GPL, but it never says that GPL'd code must be posted on sourceforge. If I understand correctly, only those who receive the executable need to have access to the source.
Of course, the question becomes "why bother with the GPL?" At this point, its use becomes solely a matter of philosophy.
I'm sure more capable people will eventually answer, but I'll try to provide my answers to the first two questions at least.
As to making money, most of it seems to boil down to "we don't sell products, we sell services/solutions!". Additionally, it is (IIRC) perfectly conforming with the GPL to sell your program for cash (see: Stallman and Emacs), it's just that it becomes difficult to force more than the first customer to pay up if they choose to redistribute for free...
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.