Reasons NOT to open source not-for-profit code? [closed]

Question

I am a big fan of open source code. I think I understand most of the advantages of going open source. I'm a science student researcher, and I have to work with quite a surprising amount of software and code that is not open source (either it's proprietary, or it's not public). I can't really see a good reason for this, and I can see that the code, and people using it, would definitely benefit from being more public (if nothing else, in science it's vital that your results can be replicated if necessary, and that's much harder if others don't have access to your code).

Before I go out and start proselytising, I want to know: are there any good arguments for not releasing not-for-profit code publicly, and with an OSI-compliant license?

(I realise there are a few similar questions on around, but most focus on situations where the code is primarily used for making money, and I couldn't much relevant in the answers.)

Clarification: By "not-for-profit", I am including downstream profit motives, such as parent-company brand-recognition and investor profit expectations. In other words, the question relates only to software for which there is NO profit motive tied to the software what so ever.

Answer 1

You need to take into account that open sourcing your code might require additional effort.

As an example, in this blog entry Sun/Oracle engineer describes efforts they had to take when open sourcing their code: Open Source or Dirty Laundry?

As we get ready to dive into the open source world, one of the many activities that's occurring is the preparation of the code for being open sourced. There are some obvious things that need to be done. For instance, our source code includes a mixture of code that we've written and code that we've licensed from others. We'll need to separate out the latter and open source only the appropriate pieces of code.

Another preparation activity is "scrubbing" the code of proprietary information, mentions of particular customers, developers, technologies etc. This is a little less obvious, but consider the following example:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

While all of the above might be true, we probably have a relationship of some sort with Intertrode Tech and having comments like this in the code could hurt our business somehow and so it should be removed. Arguably it shouldn't have been there in the first place, but now's the time to take it out.

Another part of the "scrubbing" activity is to remove profanity and other "undesirable" words...

Note all above changes had to be made to code that has been considered perfectly OK as closed source - that makes it pure extra effort so to speak.

Answer 2

Security.

For example, say you build a web framework and you yourself use it.

As a not-for-profit project, you haven't had the time to dedicate to inspecting every bit of code for vulnerability to one attack or another:

• CSRF
• XSS
• SQL injection
• Session fixation
• Use of buggy third-party libraries or even languages

Now, having open-sourced the project, you allow friendly eyes to contribute, but you also allow malicious eyes full insight into your work, and, if they find a server that is running your code, you've eliminated your ability to hide your imperfections in obscurity.

Of course, this may not apply to the type of software you are working on; and as always obscurity is no excuse for laziness in security.

However, just like I found in the couple of the levels that I got through in the Stripe capture the flag game, knowing the code is the among the easiest ways to find vulnerabilities (and sometimes it can be the only way).

Answer 3

A good reason not to open source is that some of your source might be copyrighted. How often don't you search the web for a quick solution to a problem and just take the snippet of code you find?

Well, those might be copyrighted and I don't know if the author would like finding his code being relicensed under a different license.

Answer 4

You need to be careful with how you choose your license to avoid potential liability issues.

A lawyer may be a better person to talk to about this, but the general idea is what happens if someone uses (or misuses) the application and it causes some harm? Are you responsible? Obviously this would depend on what type of software you are writing, but you always need to be careful with what your license says about your liability. This can be a tricky thing to get right, so it may be easier to just not release the source code.

Answer 5

Warning: I Am Not A Lawyer.

Well, if it's a not-for-profit and its intellectual property is strongly tied to the software's code, then some may want to protect it from being commercially re-used, or even abusively exploited to create carbon-copies of your software.

Some other reasons - which are probably deep-rooted in the first one, actually - are that in your case a lot of the high-end research happens with private funding, and usually the investors want to see ROI. And so far, no all actors of the software industry (or newcomers) have been fully persuaded of the viability of the open source model (most likely by lack of knowledge and understanding of licensing, or by simple fear that licensing won't prevent malicious uses and copies).

Additionally, these companies don't want to get sued back by the ones who attempted to make a profit on their backs, and licensing is seen as a safeguard in this regard as well, with good reason or not.

It may not appear so, but maybe not-for-profit organizations ARE profitable for their founders or investors. The benefits just aren't direct. So they have a great interest in the NFPs going strong and not being beaten to the curb by competitors (even though you also wouldn't often think of "competitors" in the not-for-profit market), and they want to preserver their IP, even if it's at the cost of not getting more free eye-balls to review their code to find problems and improve it early on.

Note as well that copyright laws differ from country to country. Many European countries consider US copyright laws and the US patent system to be rather dumbstruck, for instance, so there's a cultural background and weight that is hard to shake off.

Jut my 2 cents on the subject.

(I've worked with universities a lot, and recently in bioinformatics and healthcare... It's a recurrent question for me and my colleagues :) )

Answer 6

There are at least two different kinds of open source.

If your attitude is "here's something useful, I'm done with it" (and that turns out to be accurate) then there's little downside.

On the other hand, if your attitude is "I'm really excited and I want some real users to help drive future development" then think very carefully. You will have to spend time supporting users, many of whom are clueless. You will have to consider conflicting requests for features and enhancements. You will find it increasingly difficult to make changes, to preserve backward compatibility.