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.
Non commercial software = less unneccessary and non-core expenditure for businesses = more money for research and development, capital investment, salaries and wages, and marketing = better economy = better for the people.
The reasons?
1) Installing software correctly (apache, mysql, sybase) is a time thief. Installation is sooooo much more straightforward in Windows.
2) Propagating changes in configuration (and new versions) is a hell in Linux, especially Sybase and Oracle products.
3) Less documentation (usually) from commercial vendors.
4) Worse support (usually) from commercial vendors.
We're hoping to see long term effects in stability. The problem is that NONE our eight Windows 2000 servers has ever crashed...
That said, Linux is so much cooler.
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.
that we're all hobbyists and only do OSS in our spare time (the description often made in news articles).
..." and so on.....
Not necessarily the case, especially with the more major OSS products. Companies of various sizes have staff writing and contributing OSS code as their full-time job, and many university students also contribute as part of research projects. Even CmdrTaco could fall under the category of a small-company contributer for his work on Slashcode.
The hobbyist argument is often made in FUD from MS to try and say that "we have professionals working for us, who does OSS have?" We should answer with somehting like "Redhat, IBM, Sun, Novell,
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Copied my post on the same topic at OSNews...
I'm reasonably certain that this comment will be poorly received here (at Slashdot as well as OSNews), but I just can't keep it to myself, so oh well.
Truly, the author does a good job of dispelling one piece of FUD kicking around regarding open source software, specifically the belief that most open source software is written by wild-eyed loners without any concept of planning or design.
Other than that, the article is, umm, not so good. Nearly everything he says about closed source processes describes "big company" closed source processes. I work for a small closed source shop and his description of the open source development process is very *very* close to our process. It sounds as if his only closed source experience was with IBM, which is quite possibly the most extreme example of a process-bound company one could imagine.
Since analogies and similes are so popular on this thread, I would suggest that he what he is saying is like saying that vehicles made in Japan are more responsive than those made in America, using as examples a Japanese sports car and an American diesel locomotive.
Anybody who has worked in or with a smaller, more nimble closed source shop will see his description of the "closed source process" as bullshit. Many of these people will conclude that the author is a crank and proceed to ignore the good point he does make about the professionalism of many open source projects and companies.
The same applies to the stuff about standards. Closed source shops can and do adhere to open standards; I know we make every effort to do so in my shop. Many many open standards were originally developed by closed source shops cooperating to facilitate communication between closed source products and to offer the market choices in how to combine them. I know this is hard for some open source zealots to believe, but many closed source shops know that offering products based on open standards can help improve adoption of new technologies; when the tide comes in, all boats rise, ours and the competition's both.
Don't get me wrong, I think open source software is a Good Thing; I use it daily (Mozilla, OpenBSD, Knoppix, blah blah blah) and push it whenever I get the chance. I just don't think this article is about what the author says it's about and I don't think it will appear convincing to anybody that isn't already convinced.
PS - It also doesn't help that in an article about professionalism in the open source world he flubs "stock in trade" and "give way" in the opening sections.
If you mod me down, I will become more powerful than you can possibly imagine.
The biggest misconception is that Apache is indicative of all Open Source projects and that Microsoft is indicative of all Propriatory software providers. The fact is that every project is different, you can't lump them all together in one neat package and say "this is how all these work".
The second biggest is that if you don't like a feature or bit of functionality within an open application you can just literally "jump in" and hack the code. This completely ignores the fact that even if you can code, most products are insanely complex and it'll take you several months to truely understand how it works, how it's put together, how the pieces interract and how you should go about working with it.
Avantslash - View Slashdot cleanly on your mobile phone.
The reason most project managers don't do this is because they have the title "manager". They feel they're supposed to manage. Unfortunately, they try to manage the programmer, not the project. They also don't understand the development process. Frankly, the problems lies with upper management who've never written a line of code. Maybe the project managers should be given the titles of sales consultant or customer handler. Heck, the best project managers I've seen refer to themselves as "fecal matter" handlers. Okay it's been sanitized for the kiddies.
Business majors don't want to think of themselves as equal with the people who develop the product. Heck, they certainly don't want to be seen as doing some programmer's busy work. Why we all know that programming is "blue collar" work anyway. It probably doesn't help that the average programmer really can't relate to the issues of sales either.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
... I've probably been trolled here, but it was the early and confused modding of others that prompted me to respond to this. Personally, I would have just modded this down if there was an option for 'misinformed' or 'just plain wrong'.
Consumers don't buy software; people aren't paid to write software for the sake of writing software.
Consumers buy services and products; people are employed to provide services and products.
Software is a means to these ends, but it is not the end.
Open source provides the ability for companies to focus on the products and services they wish to sell, and employ people who specialise in those areas, rather than having or paying a bottom heavy and expensive zoo full of code monkeys. Think of all those things you need to do take a product to market - product design, research and development, support infrastructure, documentation, advertising etc etc.
You might want to rephrase your comment and say 'worse for programmers'.
But even then, if you're a company that relies on open source and is profiting from it, you would do well to remember that it's only going to work if those open source projects are maintained and supported... solution? You fund the open source projects - you don't employ people specifically, they're free to be funded by many companies and they're free to walk away too, while still leaving the option for others to take over and compete.
Sounds like a good thing for the economy (and even for programmers) if you asked me...
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.