The alternative with NO source code means the consumer is FORCED TO cut their losses and find another vendor. No other choices exist.

I think you left out some choices, like releasing the source code to the public domain or even selling it to an interested party.

You may want to convey the benefits of OSS to the "two large companies in a bit of a jam"... unless you're trying to sell them on an IBM ecommerce server and services. In that case, keep them ignorant. ;-)

I know it is a blog post, so it is not intended to be comprehensive or complete. However, many of the most important factors are completely overlooked here (value of FS), making it shallow enough to deter somebody who considers such scenario.

I faced that situation a couple of times. Companies were happy with the application but it required some minor but fundamental fixes.

So what... take the risk and support the costs of a rush into a full migration or just fix what has to be fixed?

"unless your company wants to enter the packaged software business" a bit overstated?

@Roy & Roy, in many cases the customer can have the source code, although it is in escrow. The two customers I speak of have the source in their hands now, they wish that they didn't! :-)

I thought about the point of releasing the code into the public domain, but I wasn't sure if the escrow agreements would allow it. Selling it to an interested party, is a variation of #1.

I'm not suggesting that customer "remain ignorant" to the value of source code, or that there is no value in the source.

I am suggesting that companies like these 2 customers thought they were protected, but didn't truly consider what the protection entailed. I suggest that their situation would be little different if they were using an OSS product. They would have the same rights to the code, but at the end of the day they'd be back to deciding amongst the 3 scenarios I list.

Again, I don't say source code access is bad, evil or un-American (although I'm Canadian).

@ThinkTwice,

You bring up a great point that I didn't go into. So, you have the source code and add some "fundamental fixes" or "new features". You even go as far as submitting your work back to the community. Let's say they don't use everything you contributed. You are now running a unique version of the product that (potentially) no other customer/user is. Upgrading to the next "official" product release could be more difficult, obviously depending on the complexity of the stuff you added vs. what's in the official distribution.

Again, it's great that you can make modifications as you like. But there are consequences that may impact your migration to future releases. I'm not suggesting these issues are insurmountable. I am only suggesting they are present.

You know, it's funny, but I've heard a range of IT executives say the exact opposite, and have talked about the problems they see in getting locked into a vendor's viability because they didn't have the source code. I'll take their word for it.

But even if I didn't, you're misusing the source code argument. No end user has to be in the packaged software business, now or at a vendor's demise. Your source code access is a proxy for mine. I get benefit today even if I don't touch the code for a range of reasons that I and others have explained elsewhere. And when I die, yes, you can find a range of third-party vendors to help with the code. If you'd like to buy an Alfresco subscription today, I'll send a few your way.

You are a curious open source "advocate," Savio. If you don't recognize the value of access to source code, while every one of my customers makes sure that's a central component of my company's contracts, that's a gulf of understanding I can't bridge for you. As I said before, I trust the customer to tell me what she cares about. She seems to want source code access. You might be able to warn her away from open source, but I think others have been spending far more time and money to do so.

@Matt, being an advocate doesn't mean that I have to blindly repeat "conventional wisdom".

The software market is littered with once successful vendors who tripped and lost their way. I don't fundamentally understand why a 3rd party would be more successful at "maintaining/developing" code from ISV XYZ if ISV XYZ couldn't do a good enough job to stay in business.

Seriously, if you have customers who think that a 3rd party can do a better job of supporting their needs, and potentially, developing the product in the future, than Alfresco Inc., then what does that really say about Alfresco's future viability? Are you suggesting that one of these 3rd parties would take on stewardship of the code/project/product should the need ever arise? Or are we overstating the capabilities of a "partner". (Note: I don't question Alfresco Inc's viability because I doubt any of their partners could fill its shoes today or in the future).

I am not warning a customer towards or away from OSS. I am trying to question the value of source code beyond the often repeated "it's insurance even if our company never touches it".

I don't think things are so cut and dry.

I just worked on a bid where a company wanted to upgrade 5 year old software but the original ISV went out of business. They are looking at huge expenditure to replace it in order to implement some additional functionality. The expense is huge not just in dollars but also in time because they will have to burn staff time to re-educate who they hire to relearn the business rules that makeup the current system. Because the client does have to the source, they have another, much less expensive option - hire someone to enhance the existing system.

Furthermore, as professional software developer, I hate to break it to you but access to library/framework source IS everything its cracked up to be. That's why FOSS has permanently changed the way developers work. They don't have to make excuses that a library doesn't work as expected when they are the proverbial 90% done with a project. They just fix it and finish the project.

You have a good point. However without the source code you have only the third option.

Lets take another case, Microsoft Office. Let's assume for the purpose of discussion, that Microsoft put the source code into escrow in case they went bankrupt.

Where is the programmer who is able to take the source code for MS Office and create a working application?

Personally I wouldn't touch that source with a twenty four thousand mile pole.

I might be tempted to tweek Open Office Calc though.

Savio, you're being a troll. What you fail to make clear, and in fact seem to be conflating on purpose, are the differences between having the source code to a proprietary application under escrow, and having the source code to an open source/free software application.

In the case of having source code under escrow, you have exactly zero rights to do anything whatsoever with the source code except for it to be held in trust by a trusted third party. If the vendor remains in business, then the code in escrow is not available to you. If the vendor goes out of business, then whoever buys its assets in foreclosure or bankruptcy court gets the rights to the code, not you. So escrow is nothing but a warm-fuzzy for the bean counters. In reality and practice, it is useless.

In the case of access to the source code of a free software/open source application, you have many options. If the project remains active and you have programmers on staff, you can submit your fixes directly to the project. If you don't have competent programmers, you can at least contribute bug reports, enhance documentation, request features, etc. If the community agrees with your suggestions, and in most cases they will, your contributions will be added to the project and you end up with a better product at the next upgrade. If the community disagrees, you always have the option to fork the code or to maintain your own private set of patches. If the project fails, well, you can always take over the project, or at least salvage your data. None of those options are available to holders of source code under escrow.

Have a great day!
Mark S.

@Mark,

The two companies I mentioned have the code in their hands today, even though the ISVs who wrote the code are still (marginally) in business.

I fully understand the rights you have with an OSS product. My point is that there is a wide, and often un-discussed, gap between what you can theoretically do and what you actually will do.

Go ahead, make your private patches, and tell me you're not going to have issues with migrating to future releases?

We gloss over the implicit challenges to "you have the code, so go wild with the code" that business decision makers buy into it without fully understanding the complexity of "go wild with the code".

I would rather get past the warm fuzzy analysis of the benefits of OSS....because, in the words of the wise Mr. Bon Jovi, "every rose has its thorns" :-)

[because, in the words of the wise Mr. Bon Jovi, "every rose has its thorns"]

You mentioned you were a Canadian, right?

"You are now running a unique version of the product that (potentially) no other customer/user is. Upgrading to the next "official" product release could be more difficult."

These are in a sense technical problems, and it's why OSS projects tend to embrace liberal, often bordering on fanatical, plugin and module based architectures. And OSS coders get good at messing about with patches (and eventually learn to write actual code in a way that makes patching less messy!)

Thank you, Savio, for touching on the real world decisions companies often have to make.

I come from a large systems world. Proprietary source code is the norm there (not universally, but generally). Customers routinely have FULL ACCESS to the source code and can do anything they want with it (customization of vendor code being considered routine). So escrow-specific issues do not arise.

Now, there's a long-term problem lurking in that jungle, and it's subtle. Vendors often gloss over shortcomings of their systems, saying "hey, you have full source code, you can modify it to do anything you want." And it's true!

However, the code isn't yours, it's the vendors, and they continue to enhance the product. The more you customize the more work it is to implement a vendor upgrade. All the code changes have to be evaluated and merged together to produce a usable final product your clients will like and want.

So extensive customization can become an albatross, holding you back. I've personally witnessed a vendor withdraw support because the customer was too far behind in their installs. The upgrades became unrealistic because of the manpower required to perform all the code merges. It's a trap that the customer creates for themselves!

Well, this is just normal code forking going on. It is no different with the open source world. Yeah, sure, you can contribute back to the FOSS project, but what if your company doesn't? Or as another commenter said, the community is under no obligation to adopt your changes anyway. So there are multiple ways that customs can stay custom.

And as you so eloquently said, many companies just don't want to get involved in coding. There's a skill set, a mind set, and resourcing issues there that some companies just aren't ready for, and in many cases that's entirely appropriate.

FOSS advocates over-state the benefits of source code availability. Yes, it gives you an option you didn't have otherwise. However an option you aren't interested in exercising is of no real benefit!

Savio,

Maybe you're being a little disingenuous here. Sure source code and support are both necessary for a customer to draw value out of software. When support withers, at least access to source allows other options to be explored. Without it even theoretical options are closed to the customer.

Matt is right when he says that source code is critical. Put another way, source code is necessary, but not always sufficient, condition for a customer to have freedom over its future.

In OSS land, where all software by definition has source code available, the viable/desirable ones are the ones with a healthy support ecosystem i.e. community.

I was wondering when someone was going to question if you are an advocate, or at least neutral, on open source. Thanks, Matt. Most of your posts make little sense to me. I kind of figured you were on this site as the "alternative, non pro-open-source thinker" (which I would call somewhat backwards thinker in this day and age), to try and stir up some controversy.

I think you are also missing a lot of the value from a global perspective. For example, where govts, and companies, and communities will build their commmunications and technology infrastructures on open source. So if in 2, 5, 10 or 20 years they want to keep using a certain software, or extend it in a direction that IBM, BEA, Oracle, etc don't see fit for the Thailand, Ethiopia, or Sweden markets, they can, and they have options. Similar in many sense to the ODF argument on storing govt data in a format that one company gets to control.

I know you are surrounded by that IBM SW group kool-aid, where "open source is good, but only in a nice contained place, like Linux and the bottom end of app servers". Keep inhaling, as the world whizzes by you, my friend.

Bass Fisher
A friend of the people

Oh man - Roy Russo corrected me:

"Every rose has its thorns" was not sung by Mr. Jovi....but by the glam heavy metal band Poison.

I stand corrected, with my heavy metal credibility in shreds! :-)