Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 SE, 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.

share|improve this question
    
+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 Jun 13 '12 at 5:05
    
@haylem, I hadn't seen PM.SE, but that seems like it's more for technical aspects of project management? –  naught101 Jun 13 '12 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 Jun 13 '12 at 6:58
    
@ThorbjørnRavnAndersen: yes, I'm assuming active maintenance, development, and use of the code. –  naught101 Jun 13 '12 at 7:17

6 Answers 6

up vote 24 down vote accepted

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.

share|improve this answer
2  
Well, this applies for big companies with existing code-base, much less for code that is written to be Open Source from scratch. –  Konrad Rudolph Jun 13 '12 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 Jun 13 '12 at 12:51
    
Didn't the same thing happen with DOOM 3? Patent Issue Delays Doom 3 Source Code Release –  user16764 Jun 13 '12 at 19:11
    
Accepted due to popular vote. (I upvoted most of the other answers too) –  naught101 Sep 17 '12 at 12:13

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

share|improve this answer
6  
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 Jun 13 '12 at 6:49
    
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 Jun 13 '12 at 9:10
    
Security through obscurity? –  Lukasz Jun 13 '12 at 13:11
3  
@lechlukasz Did you even read the whole post? –  NickC Jun 13 '12 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. –  NickC Jun 13 '12 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.

share|improve this answer
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. –  Amadeus Hein Jun 13 '12 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 Jun 13 '12 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. Jun 13 '12 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 Jun 14 '12 at 16:21
1  
Unethical....maybe, a very very good reason to not open source, certainly. –  Pieter B Dec 29 '12 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.

share|improve this answer
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 Jun 13 '12 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 :) )

share|improve this answer
    
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 Jun 13 '12 at 4:37
    
Clarified the question. Sorry for the hassle. –  naught101 Jun 13 '12 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 Jun 13 '12 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 Jun 13 '12 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 Jun 13 '12 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.

share|improve this answer
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 Jun 13 '12 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. –  Joonas Pulakka Jun 13 '12 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 Jun 14 '12 at 4:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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