Slashdot Mirror
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?"
Teach them about moral obligations.
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!"
Dude, I think I can see my house from here.
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.
Um, wow you would think if management whent opensource, they would understand why you would relese the code back out into the wild, tho thinking about it know, it could follow this,
You found a stray dog
You raise the dog
You train the dog
Do you give it back to its owner?
WulframII - Free Online Mutiplayer 3D Tank Shooting Game
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.)
"Not an actor, but he plays one on TV."
Try to calculate the cost involved in maintaining there own code wrt the changing public code base. Offset that cost to the added revenue by keeping their own code secret. If the numbers make sence, managers will at least contemplate it. Be sure to have a viable test program setup for this. Finally, bundle it up in a nice report, ask your direct superior for approval and put it in peoples inboxes.
For the perfect anti-Unix, write an OS that thinks it knows what you're doing better than you do and let it be wrong.
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.
Translate the following into business speak:
"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 could also play the sneaky marketing angle. Release "some" of your source (one or two features) and really "ham it up" in the press. Your competitors may follow suit, releasing "all" of their source. Profit!
So do your best to get the code out there, yet figure out a way to make it profitable to your business.
BBH
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.
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.
Hi;
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 those product are good enough, or maybe there is less interest. But for sure there is a lack of open and shared applications for the signaling platforms like Asterisk. I was happy to see that CommuniGate Pro, a commercial platform, decided to release all of its applications, APIs, and programming language open and free. The product is also now free for 5 users, and even 5 commercial users. While they want you to buy something for big ISPs, I do see the value in having an open approach and free version that is not crippled like some vendors do as a bait and switch.
My company is just getting ready to open source some of our software. We're also planning to contribute back to some open source software projects we use. Here are the biggest reasons:
- 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.
Developers: We can use your help.
As a company, why would you ever pay?
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.
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 back to the community isn't always a guarantee that your changes will make it in, or that they will make it in by the time you need it. In that respect open source projects are similar to commercial products: in both cases you are often subject to the whims of leaders who are not your employees.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
Unitarian Church: Freethinkers Congregate!
Just convince management they can replace their entire development team with volunteers who'll do the work for free, that should get them to release their changes (and you)!
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
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.
Have you read my journal today?
I see a lot of people are suggesting that you mention the difficulties of merging external code changes into your own custom code base, but one thing I don't see emphasized enough in this thread is some way to communicate that given that there's already a lot of value out there, the value that the code can build on top of your changes may be worth giving back for.
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 guess a few months worth), and propose that after that time patches get sent back upstream.
Or point out that other people have built some amazing things (I mean, you're using them, after all), and that if you have patches of general interest then they'd be able to build those amazing things on top of your patches of general interest.
I'm a coder too, I often don't understand how the pointy haired ones think either, but if you can start with something that isn't a bug fix for which you can quantify the competitive advantage (measured in months), get them to release that back into the code, and then demonstrate that people were building on top of that feature and giving that back to the code, then I think you've got a good start on putting justifiable dollar amounts on offering patches back to the community.
And once you've got dollar amounts, you're half-way to a business case.
Or maybe you'll discover that, in fact, your competitors just gobble up your fixes and don't give back anything themselves. I honestly don't know the answer to that one, but I think focusing on one feature and change that you can put direct quantifiable values to will give you and your management that answer.
How do you get candy manufacturers to give away their recipes? How do you get auto manufacturers to give away their schematics? How do you get metalsmiths to give away their fabrication methods?
Patents.
Oh... wait a minute.
That code cost time and money, and regardless of your potential maintenance costs,
/. oblig. anti-MS stmt )
your competitors will have to spend the same time and money you did (if they can execute as efficiently)
to get to where you now are.
Not to mention that some of the changes enabled the use of an open source tool,
where previously a (likely expensive) commercial tool was required instead.
This is also money your competitors spend.
Why would you want to make life easier for them?
On the off chance that they will contribute back something of equal value?
Seriously, are you nuts? or have you just drunk too much FOSS Kool-aid?
The reason IBM can afford to contribute code back to the pool
is that their business model makes most of its money
from consulting services and custom projects rather than from products.
In their case, they can offset the loss of revenue from
1) increased adoption of their OSS products (making their services more attractive)
2) reduced cost of maintenance (they still contribute some of this)
3) goodwill from aging OSS developers who are now influencers or deciders
Point number 3 is particularly important because not so long ago,
IBM was seen as the evil, 800lb gorilla that Microsoft is today.
Because of their goodwill gesture, OSS developers (and the media) now refer to IBM
as if it were a largish but non-threatening member of their own band of monkeys.
OSS developers do their utmost to defeat Microsoft, but are neutral to positive about IBM.
That's a wind IBM can use when racing against Microsoft.
But if your company isn't in that league, then the goodwill will be diluted by comparison to IBM and their like.
And if your company makes most of its money off products, it won't be very willing to chance hurting that revenue stream.
Oh. And if your company IS Microsoft, then it's just because its being run by a bunch of rabid weasels
(
Contribute to open-source yourself... on company time!
Instead, use the opportunity to get more done with the same people.
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.
Got time? Spend some of it coding or testing
- They already have an advantage by using OO. (most of their competition are probably still paying for MS Office).
- Being known as a contributor to the OO community will make it easier to hire quality coders.
- They will get thousands of free testers
- They will get free support for their new code
- they won't have to re-patch OO every time there's a new version
- Free developers -- other people will improve the code that your company releases
- possible compatibility with the outside world (as their approach becomes a standard).
- not having to support this code internally will allow them to work on more productive improvements.
- This is how OO got created. If they like what they got then they should continue the process.
As an absolutely worst case (and even in addition to contributing the code), you should encourage them to make payments to the OO group.Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Even if it can't be compelled to release them, once they're out... IANAL but it seems to me the GPL applies once the cat's out of the bag. Tough noogies for your bosses if they don't like sharing. Besides, what are the chances they'd catch you?
(It's never too late to join the Renaissance)
Even if it gives you a competitive edge, there's no reason why your competitors will take it: it is infected with the viral GPL after all (if your competitors bought that load of trash, that is). If they use it and regain some lost ground they may submit bugfixes (for the same reason you did).
All it requires is a move from the mindset "we musn't let someone else profit from our work" to "if we work together, maybe the market gets bigger and we ALL get more moolah".
Our business (85%) is custom embedded firmware and hardware designs. We make some money from the few products we sell OTS; but even those are by their nature designed to be customized.
:)
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 who can afford to pay more for propietary development.
..don't panic
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 proprietary companies can't afford.
This is the kind of synergy that you get from GPLing away your code.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.