Open Source Not That Open? 339
mstansberry writes "At the Open Source Business Conference last week, Microsoft's Shared Source mouthpiece Jason Matusow argued the point that open source isn't really open. He said you can't just go changing code on supported Linux offerings without paying extra to companies like Red Hat or Novell. So as Linux is commercialized, it becomes less open. While Matusow made good points during his presentation, many in the open source community are skeptical of the idea at best."
An Open Discussion of Shared Source (Score:2, Informative)
The catch is this: change something, lose support. (Score:5, Informative)
What the article doesn't say, is that M$ [microsoft.com] has the exact same stance. You run 3rd party software with Microsoft Exchange, you lose support from Microsoft on not only Exchange, but probally your install of Windows 2003 Advance Server. Go read your EULAs from top-to-bottom, and you'll see what I mean. For any Microsoft product.
God I hate people slinging FUD around.
Re:Supported? (Score:4, Informative)
The first thing just about any vendor, MS or a reseller, Apple, will tell you when you have a problem with the OS is to do a clean install. If you want someone to fix your Windows install while keeping all your apps and settings intact, you'll be paying a hefty call out fee.
Not Surprising (Score:3, Informative)
But that isn't a big deal because MS doesn't either. It isn't like MS will support driver modification from ATI let alone anything I could come up with either so what is the advantage of MS's way?
Does my company "pay through the nose" for Centos? (Score:3, Informative)
I was at the conference and was in the audience... (Score:5, Informative)
first off, the argument went like this:
Say you're running SAP or some other large enterprise system. Say it's running on Linux. The fact that it's Open Source doesn't gain you much. You're extremely unlikely to be able to change things as companies like SAP, Oracle, etc. all specify exactly which versions of some of the various fiddly bits of Linux they support running their application on. If you deviate from those supported configurations - they don't support it.
And guess what - it's true.
Oracle isn't into supporting you bump-reving your kernel, and your upgrading to the latest c lib. They'll test a working stack - identify known issues (and work-arounds) - and that becomes a "known good" configuration. So - while you can do whatever you want with the source, that doesn't mean that other people are obligated to support it.
In any case - it's sort of a straw man argument. The fact of the matter is (and he even pointed this out) for the most part most people just use software. They aren't interested in actually modifying it in any way (substantively speaking). They aren't going to look at the source code, change it and re-compile it. Only 1% or 2% of software users are in that class. So realistically the fact that you can modify the source isn't such a huge advantage in practice. Other people have cited here what the real benefits are: Freedom of choice - you can still choose to make the change and support it yourself, and security - if the company supplying your software goes away, you still have the source...
And I see a lot of people reiterating the following OoC (Out of Context):
"But if a customer modifies the source code, [Red Hat] can't help you [without charging you extra]. They have to lock things down to provide value," Matusow said. "As open source becomes commercialized, it becomes less open."
What he meant by that - and clarified - was that Red Hat has supported configurations, and other software vendors upstream (Oracle, SAP) have supported configurations. They "lock things down" (not in the literal sense, damn us programmers are always soooo literal - I'm suprised more of us aren't fundies) to provide value - is simply saying they limit the scope of what they support... Deviations from those known configurations are not generally well supported. I'm very curious about how well Red Hat supports the following on the current set of it's "Enterprise" edition:
1> Downgrade a core component such as the C Lib, or similar library or set of system utilities that a lot of the system relies on.
2> Upgrade a core component as above.
3> Crossgrade a component like the file system to a different one.
Once that's been done, I'm also wondering what kind of support you'd get out of a company like Oracle or SAP...
Re:Worst, Microsoft, troll, ever... (Score:3, Informative)
That is just absolutely silly. If you have a support contract then use the damned thing when you get that esoteric hardware and make Redhat do something with it. then your contract is still valid. Why did you purchase it if you aren't going to use it?!?!?!
B.
Re:The Point (Score:5, Informative)
If you find a bug in a customized program, you try to reproduce it on a stock version. If it exists, you submit a bug report against that. It's their bug, completely.
If you modified the code, then you should be able to determine if the modifications are working as expected. If not, it's your bug.
Maybe you have shared your modifications with others who can help. Maybe it has already been merged into the standard codebase.
Even when it's not possible to reproduce the bug due to logistical contraints, or to determine whose fault it is, the vendor should still listen to the problem and offer guidance on how to isolate the problem.
MS source is available to some academics/customers (Score:3, Informative)
Strangely enough I have a friend who did just that. Now the research project he was working on had been granted access to Windows NT source after signing NDAs but the license was transferable if the project moved to another university, they were not prohibitted from publishing, etc. It was a pretty reasonable deal.
Some customers have source as well for the very reason many around here trumpet open source, they want the ability to make changes *iff* necessary. I know I've been very fortunate in alwyas being able to get employers to purchase source licenses for libraries we wanted to use, not the less expenside binary only licenses. It always seems to have paid off.
So open source's advantage is not that you get access to source, it is that little guys get access to source. When you are a big enough and you are buying enough everything is negotiable, even access to source code.
Don't listen to MS about value (Score:3, Informative)
Biased much? No, to provide value they don't need to lock things down (although last I heard DRM wasn't intalled on Linux distro's, you don't need a registration key to use a distro, you don't have to call up to register your installation. I'd hate to see what Matusow claims Windows is, if he believes Linux is locked down). To provide SUPPORT they need to lock it down. Linux has been able to offer value in it's distro's for years without locking it down. Although value is subjective, so I'm sure many MS cronies will disagree.
Re:you mean Redhat wont support my modified code!? (Score:5, Informative)
Ford will honor your new vehicle warranty if you modify the engine as long as the problem cannot reasonably be connected to the engine.
For example, if I install a high-flow air filter and a few months later the brakes stop working, Ford will honor my warranty. If I install a high-flow air filter and the cylinders break, Ford might be less willing to fix it under warranty. It would be up to Ford, by the way, to show that the damage was due to the modification and you can take them to court if you don't agree. Depending on what happens, it may not be worth it.
The Magnuson-Moss Warranty Act [enjoythedrive.com] is the federal regulation in this case.
This may be off-topic, but it's a common myth that if a person modifies their car, they lose their entire warranty. It's not true.
Re:Finally... (Score:5, Informative)
Shared source is Microsoft's foray into community development, started back in 2001 when Linux was just a hobby for the blue-haired ponytail set.
I think everybody except for Microsoft had heard of Linux well before 2001. I first started playing with it in 1995, and had it in production for webservers and other edge type boxes during 1997.
I've never had blue hair.
Re:you mean Redhat wont support my modified code!? (Score:4, Informative)
The same is generally true with RedHat or any of the other OSS companies. If you make some custom patches to, say, your Postfix mail server, and then you experience a bug/issue with your Apache server, they'll still help you out with the Apache problem. They'd probably help you with the modified Postfix too if you'd just keep it on the down-low.
Sweet Blue-Haired Savior (Score:3, Informative)
``Shared source is Microsoft's foray into community development, started back in 2001 when Linux was just a hobby for the blue-haired ponytail set.''
Excuse me? Am I delusional or were major, reputable companies already using and supporting Linux in 2001?
Had this nonsense been coming from one of Linux's adversaries, I would have understood, but this is coming from the reporter!
I guess, by the same token, Linux was created in 1991, while Microsoft was still struggling to establish a foothold on the PC desktop market.
Please forward my (and your own) complaints to the reporter and the editor's.
Re:The Point (Score:3, Informative)
Depends on what you did, but if you're willing to give up all rights to the mod, offer it to them as an enhancement request. They may or may not bite, but I doubt there's any harm in trying. Even if they don't like your coding style or whatever, working prototype code goes a long way for getting a feature implemented.
This article is garbage (Score:2, Informative)
This doesn't surprise me, considering the source (a CIO magazine).
Re:It all depends... (Score:5, Informative)
The code is open and you are free to change what you want. Or simply review it for your sunday afternoon leisure. Whether or not some other person or company is happy to give you support is a different matter altogether. This is just more FUD. RedHat is not "less open" it is simply a greater financial gamble if you start changing code in a RHEL supported box, either they support it or they don't. However, this doesn't change the fact that you can freely download Linux and bake it from scratch or use one of the many distros and change the code as you see fit.
Re:That's Might Only Be True... (Score:5, Informative)
I really do wish people would stop propagating that myth! Many of Red Hat's most important products are entirely closed source. Not only do you not have the right to modify the code, you don't even have the right to SEE the source code! Look at their RHN products.
In addition, it's not just code changes that will stop Red Hat supporting you. Recompile your kernel, and they won't support you until you reboot with a stock kernel.
None of the above get to me though. What REALLY gets to me is Red Hat supporting machines that have software from other vendors installed.
I recently had to upgrade the kernel on a batch of machines running RHEL 3 with Veritas storage foundation installed. On the test server, I ran into a problem - during the reboot, the server could not mount any veritas managed filesystems. If I commented these out of fstab and rebooted, I could then mount them fine. Would Red Hat support me, even though I have paid for premium support on all of these boxes ? Not a chance! They told me that it's a Veritas problem - go talk to Veritas.
Veritas of course maintain that it's a Red Hat problem because everything was working fine before the new kernel was booted, which seems reasonable enough to me. Eventually, after expending considerable amount of my own time and effort, I found and solved the problem. It turns out that Veritas needs to put a bunch of modules under
Re:It all depends... (Score:3, Informative)
Well, if your changes go upstream then in *will* be supported by the vendor at no extra cost. In any case this seems like a bogus arguement because the choice is between FOSS (you can make changes but they might be unsupported) and closed software (you can't make changes at all) - clearly FOSS gives the greater freedom and closed software has no advantage.
primarilly in that if the company you had support from goes out of business or stops supporting that software you can still go out and find someone else to support it or even manage the thing internally
More importantly (since there's no chance of MS going out of business any time soon), if RedHat don't want to do some bespoke modifications to the software for you (for a reasonable price) you can find someone who will do the modifications (and support them), or you can modify and support it yourself. Compared this to the closed environment where if the software doesn't do what you need then you have no recourse but to get the author to modify it (you try getting someone like MS to make a modification to their software for a single customer).
Additionally, for a techie, an open system is easier to debug since you can look at what's _actually_ happening instead of just having a black box and a spec saying what it's _supposed_ to do (which probably doesn't match what it's actually doing).
In my last job I did a fair amount of bugfixing work in the kernel (mainly networking stuff), which just wouldn't be possible under Windows - under Windows if the kernel's broken then you're basically stuffed, you're not even guaranteed a way to fix it in the future because it's completely up to MS whether they fix the problem. In the FOSS world, if there is a problem which is affecting you you can either fix it yourself or pay someone else to fix it.
Re:The Point (Score:3, Informative)
Not true. Amazon.com uses Red Hat for a lot of internal stuff that they have modded out the wazoo and Red Hat still supports them and even HELPS them mod their source. Of course, I'm sure Amazon pays all sorts of dough for their support contract, but if you are willing to pay, it can be done.