In my previous company, for some client I have written e-payment gateway plugin , since the code shipped from e-payment provider was pure horror(PHP 4, very old code). It is for a domestic e-payment provider here, and the implementation was very difficult for not so technical skilled people.

Anyhow, plugin is working correctly after testing, and since I saw a lot of people needing this, I spoke with my manager to open-source it on Github. He asked me why, and I said first of all because it's showing that the company is willing to do something free for the IT community, and second of course is to promote themselves and their services. You may think for most of the open source, that's is coming from some company, to be like first reason, and most people do. But in my opinion the second reason is what's all about, and it's perfectly normal to do it.

You give some part of your modules for free, and if people who are going to use it are interested in some extra customization with them, they will probably hire you to make necessary changes instead some 3-rd party, because nobody knows them like you do. Right? :)

In general, I think a company should always consider giving code to the FOSS community, whenever they use FOSS libraries themselves. Let's say they use Node.JS and on top of that add MIT-licensed packages from NPM, then they should make sure to also return code.

One way to contribute code back is by sending fixes, improvements and added features upstream. Another way to contribute is by separating general-purpose parts of the secret code base and packaging them into a separate module, which they release under a permissive license (MIT, BSD, Apache, MPL,...). It should, of course, be something which is still missing from the ecosystem, or something for which there are only abandoned libraries available.

A company should push such software into the open, in order to get the added benefit of

• more contributors
• a community who uses the library and tests it ("battle-proofing" it that way)
• bug reports and test reports from the community
• a company can improve its brand name ("""all hail Facebook for they have given us React""")

Here is a list of questions I use:

• Is the module a strong part of my whole system? In other words, is it the module, or one of the modules, that generates the income? If so, it’s clear this MUST NOT go open source
• Does it work without the main module that is proprietary? If not, it’s clearly not useful for anyone else
• Is it a clear solution to a problem? This is not a definite show stopper, but if my module tries to be jack of all trades, it will die pretty soon
• Is it useful for anyone else? If the module solves a problem that is only mine, that usually means I do something wrong, and I don’t even need the module (nor does anyone else)
• Is it one of a kind, or at least close to be? Again, if not, I may be doing something wrong. Reinventing the wheel is usually a bad idea, and it’s much better to contribute to an already existing library than writing a new one.