Slashdot Mirror
Open Source Not That Open?
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."
What TFA is saying (while being overly general) is that when you move outside of the box to an unsupported configuration, you lose support -- and if you want support, you'll pay through the nose for it.
What the article doesn't say, is that M$ 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.
da w00t. mtfnpy?
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.
OK -
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...
You're right in not expecting specialized support on your modified code, but I think you left out some important points.
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.
"Ford wont honour my new vehicle warranty if I modify the engine?"
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 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.
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.
Norman Cook's Ode to Sl
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.
11*43+456^2
Actually it sounds like he doesn't get the Open bit to begin with.
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.
-if at first you don't succeed, stay the heck away from paragliding.
Except that everything that Red Hat makes is open source.
/lib/modules/$(uname -r). On a boot without these, it tries to copy them in place, but as the filesystem is read-only at this time, it fails. So the problem appears to be a shared Veritas / Red Hat problem, but at the end of the day, I don't care - I pay 2 companies for premium support of their products, and I don't think I got this!
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