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.

  • +1 as I find that an interesting question myself. But I do wonder if this is the right place to ask this. Maybe you'd get different perspectives from other SE sites, like the PM.SE site. Just a suggestion.
    – haylem
    Commented Jun 13, 2012 at 5:05
  • @haylem, I hadn't seen PM.SE, but that seems like it's more for technical aspects of project management?
    – naught101
    Commented Jun 13, 2012 at 6:50
  • Will you actively maintain the project afterwards or is it a code graveyard. In other words, what is the future of the project.
    – user1249
    Commented Jun 13, 2012 at 6:58
  • @ThorbjørnRavnAndersen: yes, I'm assuming active maintenance, development, and use of the code.
    – naught101
    Commented Jun 13, 2012 at 7:17

6 Answers 6


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.

  • 2
    Well, this applies for big companies with existing code-base, much less for code that is written to be Open Source from scratch. Commented Jun 13, 2012 at 12:48
  • 1
    @KonradRudolph OP mentioned I have to work with... code that is not open source (either it's proprietary, or it's not public) meaning it has not been there from scratch
    – gnat
    Commented Jun 13, 2012 at 12:51
  • Didn't the same thing happen with DOOM 3? Patent Issue Delays Doom 3 Source Code Release
    – user16764
    Commented Jun 13, 2012 at 19:11


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

  • 7
    This debate has been going on for ages, and my impression was that open source is better for security, but only if the project is fairly popular (among developers at least). It's odd that there's not a really good run-down of the arguments anywhere on the 'net (that I can find, anyway).
    – naught101
    Commented Jun 13, 2012 at 6:49
  • 1
    In Combination with naught101s comment that makes a lot of sense. If to less people care about your source and you're using in in production the chances are pretty good that someone "evil" will inspect it and use it against you (eventually)
    – schlingel
    Commented Jun 13, 2012 at 9:10
  • 3
    Security through obscurity? Commented Jun 13, 2012 at 13:11
  • 3
    @lechlukasz Did you even read the whole post?
    – Nicole
    Commented Jun 13, 2012 at 13:12
  • 1
    @Oleksi Thanks, but I know that. I said "obscurity is no excuse for laziness in security." This question is not about the open vs. closed, it's about opening a previously closed system. I happen to completely agree with the link you posted, but developers are not perfect and when you open source a system there is a chance that the first eyes to find a bug will exploit it instead of fix it for you.
    – Nicole
    Commented Jun 13, 2012 at 16:32

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.

  • 1
    +1 for copyrighted. Just wanted to add patents as well. You might just find out that your open-source project is infringing on some of the thousands upon thousands of software patents inhabited by the "corps". Streaming video? Patented. Pay-per-click ads? Patented. Just some examples. However, chances are the "corps" don't care - unless you're a competitor. Commented Jun 13, 2012 at 10:01
  • 1
    Hehe. That's not really an argument against open source, but against piracy. But you're right, I bet this is a problem in a lot of large private code.
    – naught101
    Commented Jun 13, 2012 at 12:31
  • 1
    @naught101 Agreed. Open source only exposes the problem. Closed proprietary in this case is a matter of not getting caught ;)
    – Andres F.
    Commented Jun 13, 2012 at 17:04
  • So you are saying that one reason to keep source closed is to allow you to hide casual copyright violations? Don't you think that's a rather unethical reason to use?
    – Mark Booth
    Commented Jun 14, 2012 at 16:21
  • 1
    Unethical....maybe, a very very good reason to not open source, certainly.
    – Pieter B
    Commented Dec 29, 2012 at 19:37

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.

  • 1
    Yes, that's a good point, and most OS licenses usually have some arse-covering text in there somewhere. I guess I was assuming a "no-liability accepted" type license.
    – naught101
    Commented Jun 13, 2012 at 4:42

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

  • Hrm.. I was kind of considering the code and the IP together in my question. Maybe I should have made that clearer. I would think of ROI and branding considerations as profit motives... (I realise that "science" was a bit vague, and that lots of science is profitable - my field (earth system sciences definitely isn't though).
    – naught101
    Commented Jun 13, 2012 at 4:37
  • Clarified the question. Sorry for the hassle.
    – naught101
    Commented Jun 13, 2012 at 4:40
  • I'd consider your field to be profitable. It may not have a wide market, but it doesn't mean it's not profitable. In fqct, I'd consider it to be involving fairly big money. Why do you feel otherwise?
    – haylem
    Commented Jun 13, 2012 at 4:47
  • I'm in climate modelling. No-one pays for climate models. No-one pays to use climate models. There is no profit to be made from using the software. People get paid to do research using those models (and this often includes writing the models), and computing time is sometimes paid for, but both of these mean that sharing code would make things cheaper (more time to spend on research instead of writing code, less time wasted on HPC facilities). I don't really see how the software is related to any profitability.
    – naught101
    Commented Jun 13, 2012 at 4:58
  • 1
    @psr: I think that's naught101's point: there are profitable outcomes to the results of the model's uses, but not necessarily much money being done in selling software implementing the model. Surprises me as well, but could very well be.
    – haylem
    Commented Jun 13, 2012 at 18:22

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.

  • 3
    I don't really see how releasing code obliges anyone to provide support? And in science at least, most of the users are pretty clued up, at least about the process, if not the code itself.
    – naught101
    Commented Jun 13, 2012 at 5:00
  • 1
    @naught101: Obligates no, but if anyone uses your code, you will get e-mails, questions, suggestions... which will take some effort to handle, unless you simply choose to ignore them. Outside science, many users aren't too clued up so you may find yourself helping folks with elementary set-up issues etc. simply because you happened to release some code. I've experienced that, at least. Even BSD-style disclaimers "provided as is" etc. don't - and shouldn't - stop people from asking help. Commented Jun 13, 2012 at 8:53
  • 1
    Upvoted because this answer isn't really any less applicable than many others. @JoonasPulakka: of course it shouldn't stop people from asking for help. But it should stop them expecting an answer. Also, if you've got the actual software out in public, then presumably you have the same responsibility to users regardless of whether your code is public (depending on the EULA, perhaps). Maybe you have to expect more queries from developers if you release the code, but it'd be nice to think that most of them will have a bit of a clue, and might repay some advice a patch or two..
    – naught101
    Commented Jun 14, 2012 at 4:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.