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?"
start small (Score:4, Insightful)
Re: (Score:3, Insightful)
-nB
Re: (Score:2)
Reasons for releasing code to the open source community:
* If there is no direct value to your competitors then why not? If the goals of the project are not the goals of your business then you won't be helping your competitors.
* Bug fixes and maintenance are now naturally outsourced.
* You get more control of the open source project itself through inclusion of your code, and through
* Increased respect for your developers and your company in the community
* Adding feature
Re: (Score:3)
For example, imagine if Google decided to release all their code back into the community. The PR it would bring them would be negligible, but EVERYONE would be scrambling to grab hold of their code to use it. The competitive risk far outweighs any benefits.
Re: (Score:3, Insightful)
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 sa
Re: (Score:1)
Re: (Score:3, Insightful)
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
Re: (Score:2)
Bingo. That's the key right there... as long as you don't
Banking and Secrecy (Score:5, Informative)
Much of this code could have been released to http://cpan.org/ [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.
Re: (Score:1)
Re: (Score:2)
Even if you're right, you'll still be fired and have 1000s of dollars of legal bills. My advice is to get a job somewhere sane instead. There are plenty of code monkeys that can write insecure proprietary software, but the number of people that can write good open source software is much lower. Hence, finding some place to use that skill will probably get you a better job anyway.
Re: (Score:3, Insightful)
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 ca
Re: (Score:2)
I've seen low profile submission of patches being a great way to start. This is often easy to explain and justify to your manager, and no one else needs to know about it. The developers are glad to get a good patch, so they will welcome contributions on the
Re: (Score:3, Insightful)
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 ther
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.
Re: (Score:3, Informative)
Re: (Score:2)
#1 - Cheaper to Share the Cost of Maintenance (Score:4, Insightful)
Re: (Score:2)
Short answer: money (Score:2)
cost analysis (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
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: (Score:2)
Do the math. Calculate out how many hours it's taking you guys to merge new updates into your code and how much money per month/year it's costing you. Then tell management you can cut that by 90% by contributing code back, and ask them whether it's worth that much to keep that "edge" they're talking about.
Unfortunately this won't help if the changes are seen to be part of a 'competitive advantage'.
What would help get things started is isolating that code that most definitely does NOT give any sort of competitive advantage, and encouraging the company to release those changes. Don't push to release everything, just a few 'insignificant' bits. Some is better than none.
The parent's point is a good argument to help you get started.
Business Speak (Score:2)
"By releasing our changes, and encouraging others to do the same, you can receive enhancements and bug fixes to those changes at a cost lower than developing them in-house." If it is a piece of software that gives you an edge over a direct competitor using the same software, do a cost/benefit analysis and figure out whether it's worth while to release it. You may even be able to negotiate an agreement with that competitor to "both" release your source.
You co
Re: (Score:1)
The don't downsize (Score:2)
Spreading the workload should imply that the people in MegaCorp can spend more time focussing on the solutions that MegaCorp wants, & less time with basic adaptation & repeated work like re-applying patches.
Maintenance costs (Score:2, Insightful)
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
"Contributing back" isn't always best... (Score:3, Informative)
As a manager, I'd also be tempted to solve the "wasting time on custom code" problem by either looking at a commercial package that keeps us out of the custom code business or outsourcing the custom code bits.
Also, sending
Re: (Score:2)
I was thinking along the same lines, and wondering what arguments could be made by a company which wants to contribute a large set of patches and what arguments could be made by the project lead in th
Re: (Score:1)
Re: (Score:2)
And you'd thus in many cases you'd be a shitty manager:
a) It's likely no commercial package meets all your requirements
b) Switching has a large upfront cost (migration, retraining, hiring new support staff, etc.), not counting the actual cost.
c) Outsourcing is likely to just create confusion and even m
Free source vs free use with CommuniGate Pro (Score:1)
sometimes a mix is a good thing, if you look at email, there were a lot of opensource projects in the early days, sendmail, postfix, exim, qmail, cyrus, imp, horde, openldap etc. But, if you look at the VoIP area, which really is nothing more than another protocol to talk over the internet, in this case, SIP and maybe XMPP vs SMTP/POP/IMAP and DNS of course to make it all work, the opensource projects are less. Most notably Asterisk and SER.
I do not have a perfect answer why there are less efforts, maybe
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.
Re: (Score:1)
Re: (Score:1)
While certainly these companies are going to be the ones most likely to have software to give back, there are plenty of non-software companies that nonetheless use and enhance open source software. For example, I know of biotech firms that have hired professional developers to modify various open source packages (from scientific tools to ecommerce) and, in at lea
As a company, why would you ever pay? (Score:2)
Seriously, as long as you treat the free code like groundwater and it does what you need, what's the incentive to ever kick back? The ONLY open source projects I give any money too are those that require me to do so to rebundle their stuff into commercial products I profit off of.
Re: (Score:2)
Core Competencies (Score:3, Insightful)
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 (Score:3, Insightful)
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 (Score:2, Insightful)
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.
How about what others can do on top of your code? (Score:2)
Yes, you've got a (perceived) competitive advantage by hiding stuff away, but maybe you can quantify how much of an advantage that really is (I'd
Safer to Be In a Big Crowd (Score:2)
Leak them. (Score:2)
We're pretty free with code.. (Score:2)
Whereever possible, we give changes back and our released code is free. Open source tools allowed us to build our business on a very tight budget. Good Karma.
There is still a lot of resistance to releasing source, period, though. We find smaller clients much more receptive to the idea of GPL code inclusion than larger ones
Point them at this groklaw note.... (Score:2)
Why? Well, FLOSS code doesn't have NDA provisions, so Coverity can use the results that they get with FLOSS code in their marketing literature without having to worry about getting sued. As a result, everybody gains. Coverity gets a public testbed for their code, and the OS community gets free access to a tool that many pr