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!"

open source is an acquired taste.

[yagu]

I once gave a presentation on Linux to a corporate "get together"... a full auditorium. While I shanked the Linux presentation, I did get off on an Open Source tangent that spilled over into the next time segment. Over 100 audience members stayed.

I shared my experiences about Open Source and why I thought conceptually there were a lot of great returns on investment by thinking in terms of Open Source. I suggested as a first step corporately we could begin to think of ourselves as an Open Source community whereby any code anybody created anywhere in the company be made available for use by anybody else.

Note: I did not put this out as a suggestion for "code repository", a concept I have seen fail time and time again (usually because of heavy handed requirements to "go to the well" for already written code, usually poorly written and ill-suited for the task at hand). Instead I saw this as an opportunity for real code sharing in a community whereby status (and maybe even title) was elevated by putting something out there others liked so much, they wanted to use it.

I described all of the tools, "slashcode", etc. that could provide infrastructure. The interest was palpable... but the audience was mostly tech staff. Ultimately nothing happened... as managers pretty much stated they weren't about to let any of their staff share their code to other projects.

Yes, Open Source/sharing is an acquired taste, not one easy to get corporate management to try. When and until corporate management loosens up their uptight world view a bit and be a bit more willing to share, maybe you'll see Open Source gain purchase.

#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.)

Banking and Secrecy

[justanyone]

I used to work for BankOne (now JPMorganChase) in Chicago doing Perl work for their Capital Markets trading systems. This meant writing about 40,000 lines of Perl code to decode the bank's internal reports and load 'em to a data warehouse. In the process, I had to decode some report formats that were not proprietary, as well code up some helper modules, like ones that retrieved files (recursively) from FTP sites, verified they were complete, etc., based on configuration files.

Much of this code could have been released to http://cpan.org/ nicely.

However, I signed a nondisclosure agreement (NDA) when I joined the bank saying, more or less, I won't release any of the bank's intellectual property to any third party without prior (probably written) approval from umpteen layers of management.

This kind of NDA has been more-or-less standard when joining a new firm as a developer. People don't like it when you release code to the world that gives your company a competitive edge, or might present a security risk if people knew how you were doing things (I know all those rules about security through obscurity being useless, but that's different than posting to a cracking website the protocols you use to get data from servers around the bank).

The problems of being able to contribute back this worthwhile code are legion. Many organizations are not set up to deal with this kind of problem yet. Over time, when managers come to understand that there are definite gains to be made by releasing a module to the wild, and actually find that other people like it and contribute-to/improve it, then word will get around.

I would counsel slow, persistent, quite isolated pushes for very clearly non-business-critical components to be put under the GPL into CPAN or the like. No excited "let's do this" will get the idea through. Calm, rational arguments about a component being broadly useful elsewhere and this would may mean someone else (that you don't have to pay) will fix the small bugs we don't have time for.

I think this is going to take hold at smaller companies MUCH more quickly. I work at a startup now, and we regularly contribute patches to several of the open source (mostly Python) projects we use. Why? Because we want our changes incorporated into the tree so we don't diverge too much from the standard release (which would require much more work to update when they release a new branch).

After a while, larger companies will get the message, too, and understand this business model. Compare this to flying airplanes - pilots all talk, and contribute info, so everyone is safer. Your competitive advantage is the systems you build, and how you run them, not the fact that everyone else crashes more than you do, because whenever anyone crashes, everyone suffers.