Getting Companies to Contribute to Open Source?

epiphani writes "At my company, we make heavy use of Open Source products in almost all work we do. We also spend significant amounts of time customizing these packages to our needs, be they for performance or functionality. With the exception of actual bug fixes, we are not generally permitted to return those customizations to the community. The GPL allows us to customize these packages for internal use, and we do not distribute our changes outside our organization. Being an open source developer in my spare time, I can see the value of these customizations, and can see how they could be improved by releasing them into the community. However, the company does not allow us to return them because they are seen as our investment and as our competitive edge over others in the same market. We have thousands of hours of code development and packages we are being forced to maintain internally as a result. How can I, being a lowly developer, convince our management that it makes more sense to release many of these customizations back into the Open Source community? How have people convinced old-corporate management that its a good idea to give away something we just spent three months building?"

Comments

start small

[iocat]

Start small, with a dicrete component, and emphasize the PR benefit. "MegaCom Gives Back" will raise some goodwill for the company. Talk to someone in PR/Marketing -- they are always looking for new press release to do. Now is a great time too, "MegaCom gives back for the Holidays!"

Re:start small

[networkBoy]

You hit it on the head. Get the marketing dept to think it is a good idea then you have your own marketing department working to market your idea to the bosses :-)
-nB

Re:start small

[blincoln]

The competitive risk far outweighs any benefits.

I disagree. It would lend weight to the idea that other companies should do the same. How many of the OP's employer's competitors are writing code that's functionally the same and also keeping it secret? They're not maintaining an advantage, they're all wasting time doing the same thing on their own.

One more company giving its work back to the community may not make a difference, but it helps move the aggregate of all companies in the direction of doing the same.

I say show them the simplified game theory segment in A Beautiful Mind. Everyone trying to get an edge, and everyone losing as a result.

Re:start small

[DerekLyons]

Start small, with a dicrete component, and emphasize the PR benefit. "MegaCom Gives Back" will raise some goodwill for the company.

Sure - it will create some goodwill. Mostly among the F/OSS community, which is unlikely to be MegaCom's target demographic. It'll give the Slashdot and F/OSS folks a few warm fuzzies - but the net PR result will likely be close to nil.
 
The fact that this same lame question keeps getting asked and getting the same lame and predictable answers should be a clue that there really isn't a business case for "MegaCom Gives Back". It's a political and philosophical activity.
 
From TFA:
 

How can I, being a lowly developer, convince our management that it makes more sense to release many of these customizations back into the Open Source community?

We see these questions (or ones very much like them) on Ask Slashdot on a fairly regular basis. This leads me to an Ask Slashdot of my very own: Why do so many F/OSS supporters see it as their holy mission to impose their political and philosophical beliefs on the company? The Slashdot and F/OSS communities would be among the first to howl about how their rights and beliefs were being trampled on if one of their co-workers suggested that their company should indulge in a faith based activity - so why the double standard?

Re:start small

[Stradivarius]

You've proved the OPs point. His competitors are playing catch up by writing code that the OP already has

Or it could be that his company is the one playing catch-up, not his competitors, who might similarly have their own secret patches to do the same thing and more. There's really no way to know unless the various competitors communicate their positions, which is probably unlikely.

Also, consider that by contributing his version of improvements to the OSS community, his company can get free maintenance and further improvements. This imposes a cost on their competitors, who now must either essentially maintain a fork of the software with their own now-incompatible secret changes (thus losing out on the community's improvements), or spend money to convert their own secret changes to be compatible with the new "official" version.

Being the first provider of a new feature allows your version to become the de facto standard. Getting to define the standard can be quite the competitive advantage, as above, in addition to whatever PR benefits may accrue.

Of course, if you're way ahead of your competition in terms of proprietary code patches, then maybe you don't want to contribute them. But you run the risk that your competitor will, thus imposing costs on you. So there's a balancing game to be played based on your estimate of your position relative to the competition.

Also, sometimes it can make sense to collaborate with your competitors to contribute to an OSS project in order to fend off, or obtain leverage over, other commercial entities that are a "common enemy". I.e. many consumer electronics makers working with Linux to prevent Microsoft from being able to exert excessive influence into their industry.

#1 - Cheaper to Share the Cost of Maintenance

[mkcmkc]

One argument is that it's cheaper to share the maintenance cost of all of these deltas, which the poster suggests is significant. (And any company that wants to use the shared code but doesn't want to share back will find itself in the same bind your's is in now.)

Maintenance costs

[Anonymous Coward]

How can I, being a lowly developer, convince our management that it makes more sense to release many of these customizations back into the Open Source community?

Keep track of the amount of time you spend maintaining those changes outside of the upstream distribution. A new major version is released that forces you to spend time patching to keep up to date? That's something that wouldn't happen if you contributed your changes back to the community. Maintenance is an ongoing cost; releasing your code is one way of reducing that cost.

How have people convinced old-corporate management that its a good idea to give away something we just spent three months building?

That's the sunk cost fallacy. How long it took you to build it doesn't alter its ongoing cost and value to you from this point forward. Releasing your code reduces your costs (less maintenance) while improving the value (always up to date). It can't change the past.

Core Competencies

[bill_mcgonigle]

Don't give back the changes that really make a difference to what you do as a company, but really do figure out what you do as a company.

So, if you're not in the backup business, the features you added to bacula should go back to the community so you don't have to maintain them.

If you're selling Widgets and the Boss thinks of WidgetCo2 has a better backup system they'll be able to outcompete you there's something wrong with your business.

Carthage must burn

[MarkusQ]

If you have the right sort of personality, and the right sort of boss, you can get your point across by repeatedly showing how silly the logic is.

For example (I actually used this once):

Me: Would it be better to buy or rent a volcano?
PHB: What?
Me: Would it be more cost effective to buy a volcano, or rent one?
PHB: What are you talking about? Why would we need a volcano in the first place?
Me: Well, we have to plant the coffee someplace, and according to what I recall, it grows well on the sides of volcanoes.
PHB: We don't need to plant coffee in the first place.
Me: But what about our competitive advantage? If we aren't drinking special coffee that's a little better than the...
PHB: Ok, I get your point. Submit the damn patches.

Of course, there were twenty or so intermediate steps, including my arguing that we should refuse to answer a product satisfaction survey from a vendor, because they might use the information to improve their product, and so forth. But since the argument against submitting patches is so weak in the first place it real was a pretty easy sell.

--MarkusQ

Moo

[Chacham]

Just a thought, don't write the code yourself right away. As on the mailing list if some pseudo-code would help implement some feature. Afterwards, code it.

Besides having submitted at least pseudocode (which someone else may just write for you) you'll be able to hear if its already beenm done.

Re:cost analysis

[westlake]

Then tell management you can cut that by 90% by contributing code back

wildly improbable claims of massive cost savings screams "Bullshit!" to management. you want to get this thing done, keep your promises anchored in reality.

Re:Banking and Secrecy

[Twylite]

This is good advice, especially the bit about "non-business-critical components".

I'm going through the process of getting company approval to release a component as Open Source, so I'll add my 2c for anyone who finds themselves in this position.

First, drag your sorry brain out of the technical trenches and understand how your business creates value. You have to understand that before your can claim that any given bit of code is or is not valuable.

Second, focus your efforts on bits of code that you can argue are not Intellectual Property; that is, they do not provide a special value or advantage to your company that would be lost by them being generally available to the public.

Third, in justifying an Open Source release of the code concentrate on the benefits of contributing the code, and the costs of not contributing the code. Your best argument will be maintenance costs -- if the code doesn't provide specific competitive value then making it open source adds potential maintainers.

PR is not a good argument. Just accept that you don't understand PR, or your company's PR strategy, and that your company doesn't give a damn about what the FLOSS community thinks about it; and even it did it wouldn't use contributing patches as a way to manage PR with the community.

Finally, do more than your company expects of you. If you are genuinely concerned about the FLOSS community then you'll be happy to contribute a bit of your own time, not just your company's time & money, right? So do some improvements of your own, in your own time. Then take those to your company and explain that they're useful to the company, but not of specific competitive importance, and that you did them yourself, you didn't do them on company time, and you'd personally like to contribute them to the community but you can't because of your contract. Now you have a strong moral argument.