Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Getting Companies to Contribute to Open Source?

Cliff posted more than 7 years ago | from the an-uphill-battle dept.

Linux Business 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?"

Sorry! There are no comments related to the filter you selected.

step 1 (0)

Anonymous Coward | more than 7 years ago | (#17131374)

Teach them about moral obligations.

start small (4, Insightful)

iocat (572367) | more than 7 years ago | (#17131378)

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 (2, Insightful)

networkBoy (774728) | more than 7 years ago | (#17131456)

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 (1)

Directrix1 (157787) | more than 7 years ago | (#17136110)

Or you could present it as follows:
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 features creates a feedback effect which increases other people's usage of the product, and therefore increases the number of contributors to the project
* Good will

There are many many more reasons to release your code, than to not. Just make sure you don't release anything that would give your competitors an easily implementable competitive advantage (which more than likely would not happen, since they probably have no idea you're even involved in the project to begin with).

Re:start small (2)

Salvance (1014001) | more than 7 years ago | (#17132328)

This may not produce the results expected, particularly if his company is a venerable leader in his field. Saying MegaCom gives back is just an invitation for competitors to steal their code.

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:start small (2, Insightful)

blincoln (592401) | more than 7 years ago | (#17134342)

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 (1)

angelasmark (856143) | more than 7 years ago | (#17135362)

"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?" You've proved the OPs point. His competitors are playing catch up by writing code that the OP already has. This one of the fundamental disconnects between OSS and profit driven corporations. In the OSS world its good if everything improves. You prefer others to gain through your efforts. Its a group effort. The goal is to improve everyone's product. In the corporate world if I'm going in a direction that increases the level of profit I get, I'd prefer my competitors not derive ANY benefit from my work. Providing indirect funding for their R&D isn't my job. I have my R&D and dev teams around to develop MY companies products. The goal isn't to push everyone's products to be better, its to improve my bottom line. Competitive advantages are to be preserved. If other competing companies acquire technology similar to what I have and remove my advantage I MIGHT distribute the technology so that there is more competition for said competing companies to worry about. Then the cycle begins again as I or a competitor work to gain a new advantage. "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." Only the people who don't pull enough of a profit are the losers.

Re:start small (2, Insightful)

Stradivarius (7490) | more than 7 years ago | (#17136530)

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.

Re:start small (1)

psykocrime (61037) | more than 7 years ago | (#17141430)

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.


Bingo. That's the key right there... as long as you don't contribute anything upstream, you're now not reallying using "Foo" you're using your own private fork of Foo, which *you* are on the hook to maintain and keep compatible. And the longer this goes on, the more your version diverges from the core code, which makes it progressively more difficult to merge changes *from* upstream. Keep it up long enough and you lose many the benefits of using an open source package in the first place.

In some cases this may be an acceptable trade-off, but it's definitely a point that should be considered.

Banking and Secrecy (4, Informative)

justanyone (308934) | more than 7 years ago | (#17132584)

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/ [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:Banking and Secrecy (1)

Eagleartoo (849045) | more than 7 years ago | (#17133798)

What I would like to know is about the routines that you wrote for your employer. Did your employer commission you to write these programs? Did he pay you specifically to write tools or did he pay you to maintain systems already in place. What it sounds like to me is that you made your own tools to make your job easier, and if they are your tools - well "Do what thou wilt."? Or am I thinking incorrectly here?

Re:Banking and Secrecy (1)

jrockway (229604) | more than 7 years ago | (#17134286)

> Or am I thinking incorrectly here?

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:Banking and Secrecy (0)

Anonymous Coward | more than 7 years ago | (#17135804)

In the US, anything you create at work is likely owned by your employer; either because state law or an intellectual property agreement you probably signed when you were hired. Anything you do on your own time while not at work may also be owned by your employer, depending on what that agreement you signed says, whether you're an hourly employee, the laws of your state, and the phase of the moon.

I suggest you (and everyone who creates anything as part of their job) read this [perlmonks.org] . A prominent member of a Perl discussion site was informed by his employer that they owned every piece of code he had written since he started employment with them, including contributions to several open source projects. And they did.

Re:Banking and Secrecy (2, Insightful)

Twylite (234238) | more than 7 years ago | (#17143270)

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.

Re:start small (1)

plcurechax (247883) | more than 7 years ago | (#17134340)

Actually in my own experiences I'd say, start small, and keep a low profile. It is easier if things falter, and you don't need a Microsoft (funded or employed) rep calling your boss's boss to ask them FUD-fueling questions like "what about the liability?"

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 their technical merits.

Telling your manager that if you submit the patches to the project, you don't have to waste your in-house time re-applying those patches every time the open source project is updated. That makes it a simple benefit of direct (future) pay back in saving time in the near future, with little risk of exposing any in-house secrets or liability.

Screw the PR, I use open source / free software not to be cool, but because for my job it often the wise choice (i.e. better).

Re:start small (2, Insightful)

DerekLyons (302214) | more than 7 years ago | (#17135754)

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?

open source is an acquired taste. (3, Interesting)

yagu (721525) | more than 7 years ago | (#17131408)

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:open source is an acquired taste. (2, Informative)

Intron (870560) | more than 7 years ago | (#17135772)

My company took the opposite view when it started work on open source. Giving back patches saves money because
  • we were able to start from working code that did most of what we wanted
  • we don't have to repatch each new release
  • we don't have to worry that someone else implements the same change in a different way
  • we get hundreds of free testers

well (1)

jrwr00 (1035020) | more than 7 years ago | (#17131430)

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?

Re:well (1)

gregmac (629064) | more than 7 years ago | (#17134642)

That's a broken analogy because you're not losing out on anything by giving back.. the closest parallel would be "Do you give one of its a puppy back to the owner?"

#1 - Cheaper to Share the Cost of Maintenance (3, Insightful)

mkcmkc (197982) | more than 7 years ago | (#17131442)

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

Re:#1 - Cheaper to Share the Cost of Maintenance (1)

An Onerous Coward (222037) | more than 7 years ago | (#17133874)

Even better than that, it's possible that the patches will not only make it into the trunk, but actually get improved there. Say you upload a Perl module for handling some obscure file format. Somebody else might have the same problem, but also have a group of files that exercise other corner cases of that format. When you go to upgrade your software, suddenly it handles all these corner cases, without your company having to lift a finger.

Re:#1 - Cheaper to Share the Cost of Maintenance (0)

Anonymous Coward | more than 7 years ago | (#17137346)

If you go to upgrade your software, and maybe someday it handles all these corner cases, without your company having to lift a finger may or may not seem to be a good idea to a lot of people trying to run a business.

Now that statement as opposed to: it doesn't work in this corner case, but i could change it so it can... well, that IS a good business decision.

Short answer: money (1)

kryten_nl (863119) | more than 7 years ago | (#17131508)

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.

cost analysis (2, Informative)

TheSHAD0W (258774) | more than 7 years ago | (#17131522)

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.

Re:cost analysis (0)

Anonymous Coward | more than 7 years ago | (#17132390)

You mean, of course, if that patch is accepted, which is not always as easy as it sounds.
You have to build the patch, send it in, and hope its accepted. If not, revise, send, revise, send....
Then you have to worry about which patches were accepted or rejected for the next time you update.

While sharing is a good thing, it probably won't save you any time or resources

Re:cost analysis (1)

TheSHAD0W (258774) | more than 7 years ago | (#17133524)

That's why I said 90%. Hey, the idea is to paint a rosy picture, not to bother your managers with "details". ;-)

Re:cost analysis (2, Insightful)

westlake (615356) | more than 7 years ago | (#17136856)

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:cost analysis (1)

bakes (87194) | more than 7 years ago | (#17142798)

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 (1)

BigBuckHunter (722855) | more than 7 years ago | (#17131550)

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

Re:Business Speak (1)

dunementat (1000702) | more than 7 years ago | (#17134118)

Unfortunately if this is too successful this may make any people who are just writing code at your company ultimately useless. Remember: downsizing is cost-effective if your employees don't need to work as much as before!

The don't downsize (1)

leonbrooks (8043) | more than 7 years ago | (#17138296)

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.

Maintenance costs (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17131624)

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.

"Contributing back" isn't always best... (2, Informative)

xxxJonBoyxxx (565205) | more than 7 years ago | (#17132124)

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.


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.

Re:"Contributing back" isn't always best... (1)

dch24 (904899) | more than 7 years ago | (#17132510)

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.

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 the open source community.

I'm assuming everything stays rational. For example, if the company just announces on the mailing list "here are 50,000 lines of code, please apply patch," the project lead isn't going to accept that.

So the company would have to start small. Perhaps they would just submit a few patches implementing some of the critical core functionality of their customizations.

Then some time would elapse while the community adjusted to that. Perhaps the "open-sourcing" project would be handled by one developer in the company at first, while they got the ball rolling.

There are definitely potential disagreements where the project lead doesn't want to change the direction of the project to meet the business needs of the company. In this case, a compromise would prove the mettle of the company developer who could harmonize the company's code with the project's goals. It would surprise me if the functionality couldn't be included somewhere.

I'm thinking of the way IBM became a significant contributor to the linux kernel.

Re:"Contributing back" isn't always best... (1)

Ezzaral (1035922) | more than 7 years ago | (#17132796)

Whether or not custom code is appropriate in their particular case is irrelevant. The point is that if you have spent a considerable amount of time fixing or improving open source software that you rely on, there is considerable benefit in contributing that code back to the project. There is the maintenance piece as already mentioned. Additionally, you benefit from continued testing and perhaps bug fixing or further improvement of your code by the larger user community. This alone can be a huge benefit, because the company who has paid for your time on these improvements can essentially reap additional free work on their software.

I can't see where concern over whether or not your changes make it in in time can really apply in this case either. You already have your changes in. They are right there in your modified version of the source. You're already having to merge them with any updates that may come out. If they are merged into the base project, that is much less work you face to integrate the newer version. In the mean time, nothing has really changed while waiting for your changes to go in.

Re:"Contributing back" isn't always best... (1)

Rakishi (759894) | more than 7 years ago | (#17135710)

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.

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 more wasted money (quality of code, communication problems, etc.), and at worst royally screw you over (outsourcers go under, their code was horrid and undocumented, enjoy).

There isn't much one can do with a shitty manager really, in some ways you have to assume some rationality and intelligence in the command chain.

Free source vs free use with CommuniGate Pro (1)

marsaro (446763) | more than 7 years ago | (#17131738)

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.

Why we're about to do it (2, Interesting)

truthsearch (249536) | more than 7 years ago | (#17131760)

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.

Re:Why we're about to do it (1)

MagnusE (1019984) | more than 7 years ago | (#17138298)

I dream of the day that people will demand from the companies to open their code... ;)

Re:Why we're about to do it (1)

Alchemist253 (992849) | more than 7 years ago | (#17143334)

A lot of this discussion seems to presume that the companies involved are SOFTWARE companies, by which I mean they make money from their software.

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 least one case, gave the modifications back to the community because they never would sell the software and, at least in the one case, the changes afforded no material strategic advantage.

Management merely said, "well, why not?" when approached about releasing the source code.

As a company, why would you ever pay? (1)

xxxJonBoyxxx (565205) | more than 7 years ago | (#17131922)

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.

Re:As a company, why would you ever pay? (1)

An Onerous Coward (222037) | more than 7 years ago | (#17134034)

You lost me. Where did he say he would be giving money to the open source projects? All he's talking about is trying to contribute patches, which shouldn't cost him anything.

It is in your own benefit (1)

birdowner (635361) | more than 7 years ago | (#17132010)

Giving back patches to the original distribution helps not just everyone _else_, but also you. It is not just altruism that makes companies like Apple give patches to gcc back to the FSF. It is simpler to let the FSF handle the main distribution, instead of having to reapply the patches everytime there is a new release. The easiest way to convince someone is to show them that it helps them.

Core Competencies (2, Insightful)

bill_mcgonigle (4333) | more than 7 years ago | (#17132396)

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.

Why? (0)

Anonymous Coward | more than 7 years ago | (#17144520)

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

No need for a dev team (0)

Anonymous Coward | more than 7 years ago | (#17132668)

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

Carthage must burn (2, Insightful)

MarkusQ (450076) | more than 7 years ago | (#17133040)

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 (2, Insightful)

Chacham (981) | more than 7 years ago | (#17133266)

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.

How about what others can do on top of your code? (1)

danlyke (149938) | more than 7 years ago | (#17133706)

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.

Open source... from tech departments? (0)

Anonymous Coward | more than 7 years ago | (#17133806)

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.

Why do you think your management is wrong? (0)

Anonymous Coward | more than 7 years ago | (#17133862)

That code cost time and money, and regardless of your potential maintenance costs,
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
( /. oblig. anti-MS stmt )

DIY (0)

Anonymous Coward | more than 7 years ago | (#17134654)

Contribute to open-source yourself... on company time!

Safer to Be In a Big Crowd (1)

darkonc (47285) | more than 7 years ago | (#17138700)

  • 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.

Leak them. (1)

alexwcovington (855979) | more than 7 years ago | (#17139360)

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?

We're pretty free with code.. (1)

xtal (49134) | more than 7 years ago | (#17147474)

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.

Point them at this groklaw note.... (1)

darkonc (47285) | more than 7 years ago | (#17152464)

There's a groklaw comment from someone who noted that [groklaw.net] Coverity is using their automated bug-hunting software on Open Source code (for free!) and documenting the bugs that they find.

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?