Savio,

The example you list above is not specific not RHEL. Same with httpd: if the upstream guys don't want your patch, you have a fork :)

Want to put a patch in RHEL? put it upstream in Fedora.

Cheers,

sacha

It's also not necessarily accurate for other projects that Marc would classify "proprietary." Alfresco, for example, expressly allows such "forks" of its Enterprise code. If a customer wants to modify, we allow them to do so and encourage it.

The rest of the "proprietary distribution" reasoning falls apart.

But even if this weren't the case, there is a HUGE difference between making the core proprietary (as in code and as in every other meaning) and in making the complements/periphery proprietary (as in services like support that are only offered for a specific version or even, as in the case of Zimbra, for proprietary code in the traditional sense). In the former case the customer is locked in because the core is locked up. In the latter instance they are absolutely not because they always have the heart (and bulk) of the project.

MySQL Workbench is proprietary. MySQL Enterprise (and Community) is not. Enterprises want to be able to walk from MySQL, the company, if they have to. They can afford to do so if they have the database without Workbench. Workbench without the database...? Not very useful.

It's like what I blogged today about Microsoft open sourcing Faceted Search for Sharepoint. That's great! It's also not useful from a lock-in perspective. It means the heart of Sharepoint is a morass of lock-in. The periphery...not as much. If I'm a customer the periphery is a nice to have but the core is critical.

So, I know you really, really want to prove that nothing is different in this open source phenomenon. But it is. It's the difference between locking the house against someone or simply preventing them from using the shed out back to get some additional tools.

This is pure FUD.

If you have RHEL and you make a change to it, Red Hat will *not* slam the door in your face. If you make a change and then you call for support and it looks like that specific change might be the issue, Red Hat will ask you to back that change out to see if the problem goes away. If it goes away, then yes, they will then say that you are responsible for managing the problem since it is in the change you made, not RHEL.

If the problem does not go away, if it turns out that the problem is with the distro itself and not the one thing you've changed, Red Hat will still absolutely support you.

I can't see how this is not reasonable. If, for instance, I add an aftermarket part that breaks my car and then take it to the dealership, would you expect that they would cover repairing the car under warranty?

Sacha, totally agree.

I'm only trying to point out that having the source to RHEL (or any other product) doesn't give an enterprise all the freedoms (in reality) that they have been led to believe.

It is completely logical for RH to only support RHEL in the state that it was shipped (sans changes)...think of the support permutations otherwise!

As you point out this is not a RH-specific issue.

Thomas, fair enough. And I agree that RH (or any other vendor that follows RH's lead here) is acting reasonably.

But at the end of the day, if you tell me that I having the source code to product X allows me to make edits, but you, as the support provider for product X, will not support my edits....do I really have the 'freedom' to make edits? Theoretically I do. But would an enterprise customer pay for a support subscription and then make code changes which may invalidate the support subscription?

If you ask me, whether I bought product X or a proprietary commercial product, my 'freedoms' seem awfully similar.

Matt,

>Alfresco, for example, expressly allows such "forks" of its Enterprise code. If a customer wants to modify, we allow them to do so and encourage it.

Cool, I did not know that. So this is a capability I get for purchasing the Proprietary Open Source version of Alfresco? Where is the source code that I can make these edits? I downloaded the Tomcat-bundle of Alfresco today and don't see any source files for Alfresco.

btw, I like your House/Shed example...I'll have to think about that one more.

Savio,

in my experience with MySQL, their support is so much better than proprietary software companies that they'll work thru issues like this. not only did we make our own customized build of MySQL, we did so hand-in-hand with our MySQL support engineer who was guiding us on what to change and how best to keep it compatible with future MySQL versions. he also showed us how he funneled it into the larger MySQL issue tracker and it became part of a future release.

if you want to get hung up intellectualizing on how accurately a certain notion of freedom applies to a Capitalized Business Model, you're welcome to do that. but don't presume that enterprises and the programmers working in them do that sort of thing. we want software that works and support that doesn't suck. FOSS vendors seem to produce this more consistently than proprietary vendors.

next post please.

Thomas has made the correct point. Savio, yes, enterprise software customers do make code changes that may potentially invalidate their support agreement. The difference is, they make these changes after decompiling the source code and without the benefit of source comments or a support community. And yes, this happens at IBM.

I feel like I just wasted precious minutes of my life on this post; you're trying to pass off a truism as insight. I previously thought that you didn't understand OSS, now I see that it's not the open source part that's the problem, you don't seem to understand enterprise software at all. Have you ever been a part of a large software deployment with IBM, or any other company?

"But at the end of the day, if you tell me that I having the source code to product X allows me to make edits, but you, as the support provider for product X, will not support my edits....do I really have the 'freedom' to make edits?"

You are talking about two separate choices. The first is the freedom to change the code. You will always have that. The license grants it to you.

The second choice is the choice to buy support or not. If you don't want to support the code yourself, then you buy support.

The situation you are describing was common before Microsoft became ascendant. Many corporations had access to source, or had source in escrow for critical systems, before Microsoft's monopoly power disposed of that option. Modification of source was also common, in order to fit the software to corporate realities or strategies. They had to balance source access with support contract costs.

So, the situation that you are discussing is just another strategic corporate decision. Do you want to use the support that you paid for, or the freedom that you got for free ?

Get used to it. It used to be common, and is just another cost of freedom.

Of course, if this discussion is an attempt to make the impossible real, then you are started down the same road that Scholasticism trod in the Dark and Middle Ages, when they discussed whether God could make a rock too big to lift, or how many angels could dance on the point of a pin. Ref: http://www.newadvent.org/cathen/13548a.htm

Does anyone use open source software for desktop management systems?I have found Paragent software which seems to be looking good so far, any suggestions regarding this would be appreciated.
Thanks in advance.
Cranium1200