What is the moral responsibility of releasing open source software too soon? For instance, a close-to-complete product that hasn't been fully tested.

What is the expectation of the programmer? Wait until it is fully tested, or release to open source and then continue further development, testing, and advancements?

The fear is that software is open sourced and could potentially lead to issues for consumers.

Is this an unfounded fear?

  • 10
    Add a disclaimer if you're concerned. :) Commented Mar 4, 2015 at 4:46
  • 18
    A drawback of releasing too soon would be that the publicity boost you get when releasing may be lost if the software is unusable. Then, subsequent releases "yes, I tried that, it sucked". It of course depends on how more you need to get it in shape and the target audience.
    – Davidmh
    Commented Mar 4, 2015 at 11:07
  • @VaughanHilts I'm not concerned about somebody getting angry, the concern lies solely in the desire for the betterment of software distribution and consumption. It's the latter that I wouldn't want to suffer due to too eager of a release. Commented Mar 4, 2015 at 14:42
  • @Davidmh: That would be my main concern too, "once burned, twice shy". Commented Mar 4, 2015 at 16:19
  • 8
    Releasing the source but not binaries might be a good way to prevent people with incorrect expectations from using your software before it's ready. Commented Mar 4, 2015 at 18:57

6 Answers 6


I believe on the contrary that you should release an open source software as soon as possible. There is no "too soon" for that (but it should compile).

Or at least publish the source code very early and continuously (e.g. by frequent pushes on github), without making formal releases.

However, it is very important to flag it as alpha or beta stage, and if possible to say (e.g. in a README or TODO file, and on some blog, etc...) what is missing, not tested, or in bad shape. You should also use the version number to convey such information.

With free software, the best that should happen is that someone glances into the source code and propose you a small patch improving it. This is why you make your software free!

Hence, you need to make visible your daily work on your free software! External contributors would be pissed off if their patch won't work with, or is a duplicate of, your recent software source code.

What you should be afraid of is nobody getting interested by your software (and contributing to it). Attracting outside interest to a free software (in particular, attracting external contributors) is a long journey.



Release Early. Release Often.

Personal anecdote:

I was really excited about the project I was working on. Like, really excited. I couldn't sleep at night excited. So, I pushed my co-dev into releasing v1.0 faster than he wanted to.

It was terrible. Nothing worked the way it was supposed to. There were bugs at every turn, but we logged them and fixed them. We even had a few early adopters submit bugs we might not have found. A week or two later we released a new release that addressed a lot of the issues and then went back to building new features.

Releasing early was the best thing we could have done. It put our product in front of real users. Doing this exposed bugs we may or may not have found and made our project better. It also let those early adopters know that we're serious about this project. There are going to be more releases and active development.

It could have easily gone the other way too though. We could have ignored those bug reports. Or we could have not reacted quickly. It might have been a different story if it took us 3 months to release v1.1 instead of a few weeks.

  • 9
    It sounds like your only big mistake was calling it "v1.0". Generally users expect that to indicate a "finished" product in the sense that it's usable for its purported purpose, free of obvious bugs, etc. "Release early" is good, but users should be informed that they're guinea pigs. Commented Mar 4, 2015 at 17:50
  • 3
    Yes. I'd agree with that in hind sight. To be fair though, I thought I had thoroughly tested it. I thought it was 1.0 at the time @R... I was wrong.
    – RubberDuck
    Commented Mar 4, 2015 at 18:13

It is the same as with closed source software. Communication is important.

Inform users what the state of the software is and why it is available for download.

Software will always lead to customer issues, no matter if it is fully tested or not. Most customers do accept that fact, and some customers never do. But if the software will lead to more issues than could be reasonably expected, there is a moral obligation to inform the customer of the risk they are taking. Information should be both in short form ("Alpha/Beta/EarlyAccess" labels)*, and in detail: A list of known issues, workarounds, and special considerations, e.g. if it's likely that data can be corrupted.

*Be aware that users have been trained by some big software companies to think of "Beta" as a state where the software is rather solid, so telling the user that the software is "Beta" is often not sufficient information.

  • 3
    Should we infer that "beta" should not be rather solid? I'm guessing "big software companies" call it "beta" when it's about to be production-ready, to confront the software to real-world data. Maybe call it a prototype? Commented Mar 4, 2015 at 9:43
  • 2
    The "Beta" label now means different things for different people, so in my opinion we can't infer much from the "Beta" label other than that the software is somewhere between "somewhat usable" and "almost finished". Some customers will infer something, and not all of them will infer the same thing. That's why I put the remark.
    – Peter
    Commented Mar 4, 2015 at 10:17
  • 3
    I tend to use the term "alpha build" now for prototype builds. It gives people the sense that "This thing isn't even beta yet people! Don't expect it to be nearly done."
    – RubberDuck
    Commented Mar 4, 2015 at 10:20
  • 2
    You could distribute it in a different form, for example only in source form, without binary packages. Commented Mar 4, 2015 at 10:33
  • 3
    @SteveJessop before the gaming industry changed what we meant by "beta", I would have agreed with you. =)
    – RubberDuck
    Commented Mar 4, 2015 at 12:17

There is no moral responsibility whatsoever. No one is being forced to use your half-baked software.

The only thing to be concerned about would be your credibility.

  • 2
    without an explanation, this answer may become useless in case if someone else posts an opposite opinion. For example, if someone posts a claim like "There is a moral responsibility. Someone may be tempted to use your half-baked software. Your credibility would not be the only thing to be concerned about.", how would this answer help reader to pick of two opposing opinions? Consider editing it into a better shape, to fit How to Answer guidelines.
    – gnat
    Commented Mar 4, 2015 at 7:11
  • 6
    @gnat: It's untrue that this answer is without explanation - the explanation is the very next sentence: "No one is being forced to use your half-baked software". It is a short explanation, yes, but it still is THE REASON for saying "there is no moral responsibility whatsoever"
    – slebetman
    Commented Mar 4, 2015 at 7:14
  • @gnat: same can say about most answers. "I don't believe you should release […] It is not very important to flag it […]". Are you expecting more external sources for this answer? Commented Mar 4, 2015 at 8:38
  • 2
    There's good opinionated and bad opinionated. I agree with you, but it'd be nice to see you back it up with a stronger argument.
    – RubberDuck
    Commented Mar 4, 2015 at 10:22

My experience is that there's a balance to be achieved.

Right now, I'm working (in the sense of answering questions and providing development suggestions, without seeing any code) with a developer who's producing what looks to be a very exciting FOSS project that utilizes code I've written. The public release has been repeatedly delayed by realizations of design changes that will make the project much better in the long term, but which require significant rewrites of code that's already been written and that was already "working". My view is that, had a working but imperfect release been made as soon as there was something working to show, ideas for changes (and actual patches) could have come from the broader community that's interested in this project an accelerated it forward rather than having the issues surface slowly, one-at-a-time, as the developer thinks of them and asks for design feedback from myself and other interested members of the community. So from this standpoint, I'm very much an advocate for "release early, release often".

On the other hand, low-quality releases can make a new project look bad before it even gets off the ground. Some pitfalls I've seen include:

  • Skeleton trees with interface definitions but no code.
  • Code that doesn't successfully compile for anyone but the developer.
  • No instructions for how to build/run the program.
  • No documentation of what aspects can be expected to work.
  • Unclear description of what the program even does or will do.
  • Lack of any demonstration of usefulness.

For the last point, I'm thinking of things like:

  • Compiler/interpreter that can't even compile/run a hello-world type program.
  • Emulator that can't at least run a sample program of some sort or otherwise demonstrate that it's doing something.
  • Image processing tool that can't do anything but load and resave the unmodified image.
  • Game with nothing but a title screen.

These kinds of problems lend to a "vaporware" image that can be hard to shake unless you're very open about the lack of working code to begin with.

Finally, make your version numbers make sense. Don't call your project "1.0" until it does what users expect it to do without crashing. I've always had luck with using version numbers around "0.5" for initial public release and going from there, but I've also seen things like "0.1" or "0.10" that make sense.


There is one case when releasing free software can have negative consequences. Some specifications are licensed to the public on the condition that all implementations distributed to the public shall conform to the specification completely when first published. The publisher legally forbids you from distributing a work-in-progress implementation of the spec. Without a specific negotiated license from the spec's publisher, you must share it with nobody until it passes all tests. This forces a "cathedral model" (as Eric S. Raymond called it) on implementations of the spec.

One spec under such a license is the Java Language Specification. This restriction applies to developers of virtual machines compatible with the JVM, but fortunately not to developers of applications that run in a JVM.

The article "4 Shifty Details About Microsoft's 'Open Source' .NET" by Liu Qihao & Ciaran O'Riordan mentions the possibility of interpreting the Microsoft Patent Promise for .NET Libraries and Runtime Components to exclude incomplete implementations of the CLR in a similar manner. But again, this doesn't apply to applications that run in the CLR.

  • 2
    This is only of importance if you want to create a JRE/JDK implementation, not any java programs that run on it, AFAIK.
    – sjas
    Commented Mar 5, 2015 at 9:53
  • @sjas Are you trying to imply that JLS is the only spec that one is likely to encounter that has this restriction of "complete or keep it to yourself"? Commented Mar 5, 2015 at 15:55
  • You are trying to imply that I imply this. ;)
    – sjas
    Commented Mar 5, 2015 at 16:46
  • @sjas Thanks. Is there any other way I can make this answer useful? Commented Mar 5, 2015 at 23:37
  • I did not downvote btw. I already cleared up the misunderstanding, which I had when first reading your answer. You could include it in your post if you want to change something.
    – sjas
    Commented Mar 6, 2015 at 9:15

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