As someone else pointed out, Gartner backwards is "rent rag". You'll note in their original article that they made all sorts of wild warnings about all the liability that companies have if they use open source. It was straight out the Microsoft playbook, and I'd love to know who paid Gartner for that piece of "research".

""Just because something is free doesn't mean that it has no cost," chastised Laurie Wurster, research director at Gartner who did the survey and companion report."

And who, exactly, pays Gartner?

I've been using FOSS stuff for over three decades. Not a single one of my clients has ever complained about any of my FOSS solutions. They all constantly bitch about the non-FOSS stuff (THAT THEY INSIST ON, despite my suggestions otherwise!) ... Q.E.D.

when Linux is dominant? WIll MS still be able to afford to write their articles and do their research for them? Will anyone care?

> But sometimes a skinny bit of survey data is all you have to start with, and that data is better than no data at all

Actually, if the small sample you have misrepresents the population, it's actually WORSE than no sample at all. And of course there's no way of telling, without a bigger sample...

...that people will pay 200k licenses to MS instead of putting that money into getting what they actually want.

It's like the old 'no one ever got fired for buying IBM' now seems to apply to MS.

(Grumpy because I've put a lot of personal investment in learning the LAMPP stack and no one wants it.)

I brought my harp to the party...

Gartner won't ever see it as dominant. Because you can't make the sort of money that Gartner thinks makes you important enough to be a player (playa?).

But what do you expect, they're economists and accountants. Anything that doesn't have $/c against it is worthless.

"Just because something is free doesn't mean that it has no cost,"

And just because it is open source doesn't mean that it is free, and vice versa.

And just because you have paid for closed source doesn't mean they'll fix the bugs.

Consider a small company using a closed source product from a vendor with lots of happy customers. Imagine a bug in a particular part of the system that is fatal to the small company's product but utterly benign to 99% of the vendors customer base. Imagine also that it "smells like it might be hard to fix". Economics says the vendor shouldn't bother to fix the bug and, sure enough, that's exactly what happens.

Of course, you can always switch vendor, but issues like this may only crop up once you've burned a sizable amount of time and effort with the original product, plus the fact that presumably you chose it because the others didn't look so good.

No. If your company actually depends on the product working, your choices are "with source", "re-invent the wheel" and "without source", IN THAT ORDER. When the source is "open" or under some kind of NDA is another matter, but Gartner appear to have glossed over the issue so I will too. :)

All of the bespoke work done for the company is open source. As open as GPL or BSD is. So you'll actually have 100% of companies have open source.

Or do their in house applications keep the source secret?

There distinction between "open source" and "home grown" code is artificial and misleading.

In every sense, software developed in house is "open source" - free in fact, in the GPL sense. It doesn't have to be distributed or availanle to others outside the developing body to be so. Provided the code can be run, used in any way the user requires and modified by the user if necessary then it satisfies the requirements.

Also, it's worth pointing out that the "companies who do not have the luxury of being purists" are the same companies who have big problems when the closed source code to which they don't have access fails or is obsoleted and there is nothing they can do about it. Access to and the ability to maintain business-critical code should be an essential prerequisite for any business.

.... but just didn't know it.

Whether that's because G. spoke to the "leaders" who were out of touch with what the real people were actually doing, or (more likely) the OSS software had been delivered as part of a system from a third party. Perl and Tk/Tcl often get dropped in like that. It's very satisfying, when a caveman-ager rails against free software to say:

"we're already using it"

"WELL TAKE IT OUT AT ONCE!!!",

"we can't, it was delivered as part of <name of enterprise/database product here>",

"GRUMP (thinks: how am I going to explain this to the boss)"

I feel an El Reg survey coming on.

Home grown doesn't have all the benefits of open source until it's open sourced. It does have the benefits you mention. There is minimal cost in open sourcing home grown. Mostly cultural, in getting developers to develop in public and getting company marketeers to accept it isn't marketable as closed source in a profitable manner and company lawyers to accept the open source license it is made available under.

The extra benefits of doing so are that if you can attract other users you are potentially attracting co-developers, other people who can share the cost of testing, debugging and development. Whether it is worth the minimal cost of open sourcing home grown depends upon whether there are other potential users genuinely interested in using it to the point where other users become co-developers.

If the average small/medium (and often large) sized company has a major dependency on a particular software package - then they have support agreements (we aren't talking things like MS office here). If the supply/support company ceases to exist - then they will change software or business models - anything else is usually a sign of management failing to understand their job.

Access to the source code is pretty useless unless you have access to developers who are familiar with it and already set up development and test environments - otherwise you are talking weeks to fix that critical system problem - by which time the company will normally be in trouble (I would be surprised if company has a serious dependency on any externally source package that a new developer can pick up in days)

> Actually, IF (my emphasis) the small sample you have misrepresents the population, it's actually WORSE than no sample at all

and if the small sample doesn't misrepresent the population, then it's as good as a large sample.

Did you have an actual point?

Yes.

If you roll a dice and get 2 have you learned ANYTHING about how unbiased that dice is? It is statistically worthless. In fact, from that one number, your research would say "No, it is biased too low". And if nothing else, you spend time doing so.

Similarly here. Select all CEOs and you get a different answer from "are renumeration packages correct" than if you asked, say, outsourced call centre employees. And your decisions about such packages would be in fact INCORRECT.

Now, as to your point, how can you tell your small sample doesn't misrepresent the population? As FB said, you'll need another sample. Which would be a bigger sample.

Now, did your "point" have an actual reason or were you just verbal shitting?

"If the average small/medium (and often large) sized company has a major dependency on a particular software package - then they have support agreements (we aren't talking things like MS office here)."

BOLLOCKS!

YES WE ARE!

What is the NUMBER ONE reason why OOo isn't right for business? "All our business critical VBA".

And what happened when the upgrade from Office 95 to Office 97 cause man-months work to be man-years? You slurped the costs down like a leper's jizz. Because when you found out, it was too late to change and your sunk cost in man months to find the problem even existed could not be admitted as a mistake.

So, wrong. Wrongity wrong wrong wrong.

I've been developing on linux for a few months now after using windows for awhile. It's like going back in time to 1990, when I was a UNIX developer.

The O/S is rock-solid, never crashes, never needs rebooting. Might be promising for server-side apps.

However, the user and dev software is another story; feature-light, flakey, complex, undocumented, unhelpful. To use linux you have to be an expert in everything, from system administration to network protocols, to the internals of every tool you use. What a joy it was to return to visual studio for a personal project and be able to concentrate on writing code for a change. It's possible there is a magical set of tools that all run flawlessly and are well documented, but I don't have 'em. Sigh.

The number one reason why OOo isn't ready for business is that it chokes to death on long or complex documents or long editing sessions. It's great for one-page memos. Gimp? Terrific. I use it, even on windows. I just wish I could understand what the other 90% of it does. Evolution? crashes 10 times a day trying to talk with Exchange Server. Firefox? Stable enough for brief browsing sessions, but the error log is a confidence-destroying horror if you start it from the command line. And ugly? Wow. I work with several distros and they're only so-so at figuring out my mainstream hardware. I haven't even tried to get anything like a music player working.

If you're a windows developer wondering if you should make the leap to linux, relax. Microsoft isn't going away any time soon. You are already using the best dev tools available, sad though that is to hear.

>If you're a windows developer wondering if you should make the leap to linux, relax. Microsoft isn't going away any time soon. You are already using the best dev tools available, sad though that is to hear.

That should be better qualified: VisualStudio is indeed the Best Debugger And C++ Editor that exists. Yet, the Windows Command Line is really broken, compared to Cygwin's BASH.

I have come to the conclusion that the optimal approach is to use the best of both worlds: Firefox, VisualC++, Bash, Cygwin, tar, find, gzip, wc, grep, ssh, Subversion, iptables, Linux.

Damn, there is only one closed-source product here :-)

"To use linux you have to be an expert in everything, from system administration to network protocols, to the internals of every tool you use."

Nah. My folks (70 and 73) are quite happy with Slackware+KDE :-)

The trick is knowing how to set a given system up for a given situation. As a systems administrator, I see my role as doing my best to see to it that my services aren't needed after initial install. This is particularly true when my technophobe mom is a part of the equation ...

>If you're a windows developer wondering if you should make the leap to linux, relax. Microsoft isn't going away any time soon. You are already using the best dev tools available, sad though that is to hear.

Much like windows being used by home users. Developers like to use what they know, when I moved from visual basic to perl way back 8 years ago, I didn't like the fact that I was editing code in a text editor and running it from a command line.

But now I have the choice of editor, IDE for my python programming. What do I do? I use and editor and a set of command line tabs. Because it's quick, responsive and I can do _anything_ from any of my tabs, including research and running a python shell session to try something out or bring up the help documentation.

I've become so used to using vim and konsole that any other IDE just seems slow, clunky and not very well in tune with how I want to do things. although we could probably club together the ¥200 it'll cost to make a decent linux IDE, I just can't see the point.

>However, the user and dev software is another story; feature-light, flakey, complex, undocumented, unhelpful. To use linux you have to be an expert in everything, from system administration to network protocols, to the internals of every tool you use. What a joy it was to return to visual studio for a personal project and be able to concentrate on writing code for a change. It's possible there is a magical set of tools that all run flawlessly and are well documented, but I don't have 'em. Sigh.

>If you're a windows developer wondering if you should make the leap to linux, relax. Microsoft isn't going away any time soon. You are already using the best dev tools available, sad though that is to hear.

Yes there is a learning curve with Linux development. It starts awkward to say the least but gets better. After a while it even makes more sense than what you knew before, probably because this learning curve doesn't end in a plateau or a brick wall. More like a ladder with all the rungs there including the bottom ones. It's a question of what you are programming for. If you are programming for sysadmin and networks and servers and protocols you probably don't want to be excluded from this stuff by shiny layers of abstraction which can get in the way when you don't want them. Sometimes you do, sometimes you don't, but high and lower level APIs are all there. Also unlike MS, everything on Linux is documented if you know where to look. Much of this is in the form of manpages, some in the form of other resources, e.g. the Python API docs on the Python site. All of it is available in the form of source code when your really need it. I also tend to prefer the kind of programming development interface Martin Owens describes, over and above the all singing all dancing IDEs, given the choice of both.