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?
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.