Getting Companies to Contribute to Open Source? 57
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?"
open source is an acquired taste. (Score:4, Interesting)
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.
Why we're about to do it (Score:3, Interesting)
- PR and advertising. With our corporate name attached to some projects out in the community we get a little mind share.
- Demonstration of our expertise. By contributing features and patches back to large projects we can show clients and prospects that we know what we're doing. We're not just users of well known apps, we also know how it works deep in the code. Therefore we're worth every penny we charge.
- We'll get back more features and patches from the community. If we open source a new package (or a new module to an existing project) that people are interested in, the community will provide feedback, support, and code.
- It contributes to how good the developers feel working at the company.
We're not concerned if our competitors pick up our open source code. First, we're not open sourcing absolutely everything we have. Second, our clients get value from the custom solutions we provide. Even though we have general purpose code we can give to the community, our clients will still pay to have it customized just for them. Plus by showing we share code between projects they realize we're actually saving them development time and money.