Open Source Contribution at Work

Question

In my job I make heavy use of a couple of open source projects and we often contribute back to them. A manager I had when I first started at the company said it was okay for us to contribute work we had done on company time back to the projects and I have been working under this assumption ever since. I see a couple of advantages to contributing back to the community in this way

• The community and product improves
• We don't have to reintegrate our changes into each new release

What experiences have you had contributing back to projects at work? Do you consider it to be advantageous, a waste of the company's resources or, at worst, theft from the company?

Answer 1

As an employee, I think its a great thing and I believe more companies should have their employees doing it as it adds value to both the company and the open source project. However, I don't know what it would look like from and employer's perspective. It could potentially look like a financial drain....but then again it could look like a minimum payment for using free software which I'm sure is less than most typical licensing arrangements...and you can modify the code to work how you like and debug issues you normally couldn't.

Unfortunately, I have yet to work for a company that openly supported contributing the open source projects. Most seem to take the view that we'll just use open source stuff cause its free and lowers our bottom line but don't contribute since all code is considered proprietary.

Answer 2

I've had this situation come up, and it needed to be approved on a case-by-case basis. But the general feeling was that, as long as the code was directly related to the main project, it wasn't a big deal to contribute back. It's not like our company lost anything; the time had already been spent doing the work.

However, if you had to develop significant new features, and your competitors were using the same open-source projects, management might obviously want to keep those changes in-house. Even though it goes against the open-source philosophy, I think they would be justified in doing that, provided it doesn't violate the project's license, of course.

Answer 3

From a practical point of view - if you're doing the work anyway, there's no reason not to contribute the code back 'upstream'.

From a moral point of view, if everyone contributed code back this way, everyone benefits. It's the whole point of open-source, and without it open-source is little more that a name, and a load of visible source code.

Some companies also sponsor open projects, and even the big players (ok, especially the big players) Sun, IBM, etc. are all "doing" open-source, and have been for some time. It's about time other businesses realised what they're missing out on also.

Answer 4

Having an open dialog with your management about this would be a strong suggestion. I think it's more important to ask what your specific company thinks of you contributing to open source projects.

I personally encourage my developers do this on certain projects, but I want to know exactly what they are going to contribute, and how much time will be spent on this. From my perspective, it's perfectly reasonable, provided that I have checked over the specific thing that we're contributing, and it's not something that I need to consider as proprietary, etc.

Also, we often work on projects that are tied to sensitive data or other situations where sharing the code is not an option - and the developer may or may not be aware of the consequences. As a manager, there are times (because we're doing work for certain clients), when I want to avoid the practice - not because I think it's bad, but because I personally don't want to offend our clients if they happened to see. There are sometimes other issues at stake.

Answer 5

One of the fantastic upsides to you personally to contributing work from your job back to an open source project is that the work is now in the public domain, so you can show it to future employers. Hopefully this is among your best work, since it has gone through two separate review systems - at the job and at the open source org.

For your organization, it may be less advantageous, but if the open source project is a venerable one, then that code being supported by the organization is a huge win for your company, since it's more eyes on the code and somebody else can take over maintaining it. It all depends on what you're contributing in that case.

The downside of open source contribution for both you and your employer is that it can be a time sink. Some orgs make it phenomenally difficult to get through the obstacles to contribution. If you go down that path and find you're spending time on bureaucratic work for the open source project, just drop it and maybe try again later. You definitely don't want to push the issue and then get caught knee deep in totally unrelated work when it was your idea in the first place.

Answer 6

One possibility: people see the code you've contributed and improve on it, so you get optimizations or enhancements or whatever for free.

You also stand the chance of buying yourself goodwill within that project's community, which can lead to help down the line.

Plus, the advantage that you note of not having to re-integrate your changes can be pretty major. Say you make an improvement to a module that gets heavily redone by another contributor in a later version. If you submitted your changes, the people who made those major changes will likely have modified your code to keep pace, saving you the trouble of understanding what they did in order to patch your code to accomodate them.

Answer 7

In my experience (manager) it's been a bit of a headache. It's too easy for a conflict of interest to arise. Some developers just want to build it out on the company's dime, even including features that the company doesn't need (or worse, doesn't want).

It's tough. In theory I like the idea of making non-core stuff available in this way, but in practice I've had to manage it more than I wanted to (basically I didn't want to have to manage it at all).