So I have this project, that I've been working on for a while now(at this writing, ~2 months).

Basically, the goal of the project was to rewrite a system I built earlier so that instead of being ~930 lines of code in one file, it might be 1500 lines spread out and organized accross multiple files. Now that it's nearing completion, however, I'm faced with a dilemna: should I 'release' this project, and sell it to potential buyers, or should I release it to the community, as open-source?

The project is built to be easy/simplistic to maintain, and easy to extend/modify. I've documented it fairly thoroughly inside and outside of it, so that anyone who is tech-savvy enough to create a MySQL database could install it.

It has an install script, which I created, that makes it easy for people to install. It wouldn't be all that difficult(or at least, that was the goal) for someone to add their own mods to it, and use all/some of the core modules, or to change the behaviour of it slightly.

In essence, it's built to be customizable, and I'm proud of it. But I'm still stuck with the issue: Release it, and sell it to potential buyers, or give it to the community, and let them do what they will with it?

Replies are listed 'Best First'.
Re: To Release or To Open-Source?
by tirwhan (Abbot) on Nov 22, 2005 at 07:06 UTC

    Why not do both? Release the application as open source and offer support and/or customizations for paying customers? Or release it under the GPL and require a commercial pay-for license from customere who want to integrate it into their own non-GPL applications (this is the scheme MySQL uses). This obviously depends on what exactly your application does, but there are quite a few business models that can be built around open-source software, maybe you just need to pick the one that fits best for you.

    That being said, Moriarty is right, of course, do whatever you feel is best. Releasing your application as open source gives you a few advantages, like some free advertising and bug-testing, possibly even some contributions from other developers (though these may just be in the form of bug-reports). And that warm fuzzy feeling of course :-). But warm and fuzzy doesn't pay the bills and if you're looking to make money from this project a commercial license may be better for you.


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
      Why not do both? Release the application as open source and offer support and/or customizations for paying customers?

      And a pretty manual, too... OSS people don't expect good manuals with their software, but paying customers do. In fact, O'Reilly publishes lots of expensive manuals for free software. There's a market for that.

Re: To Release or To Open-Source?
by Moriarty (Abbot) on Nov 22, 2005 at 05:54 UTC

    Essentially, this is up to the individual. If you think people will pay money for it, and you don't mind doing all the support work, then sell it. If you think the benefits of releasing it to the community (feed-back, improvements, etc) are better than monetary gain, then release it as open-source.

Re: To Release or To Open-Source?
by dragonchild (Archbishop) on Nov 22, 2005 at 13:23 UTC
    To further echo tirwhan's response, I've been paid to write custom versions of modules I've released to CPAN. I've also been paid to expedite enhancements to modules I've released to CPAN. OSS doesn't mean free as in beer - it means free as in speech.

    Another way to look at it is RedHat - how on earth do they make their money? :-)


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: To Release or To Open-Source?
by samizdat (Vicar) on Nov 22, 2005 at 13:43 UTC
    The issue of support is a big dog. You need to be able to sell a lot more copies than you will have users who bug you. Do you already have a company framework set up (even if for another purpose) which can be used to field phone calls?

    Just as importantly, is it a project that sells itself? Is its purpose so crystal-clear that everybody just has to rush out and buy it? If not, you need to be sure to include enough money for shmoozing magazine editors and creating marketing folders.

    If you can build it in two months, why can't someone else? Time and again, open source developers duplicate payware products and take away many paying customers. Not all of them, because there will always be droids who will not touch open source and/or work only in Doze.

    If all you want to do is to support yourself, the suggestion to release your core code, especially with a gee-whiz save-the-world application that gets you publicity/notoriety, is a great one. You can then get work customizing your framework for paying customers or writing books about it, like the R* on Rails guys.

    Be careful. Betting your future on business is just as perilous as betting the stock market will go up when you need it to. I've burned $300K+ on one business, and I'm working hard to make it back (and more) with another one. Be sure you're ready to take on all the other attributes of a successful business (money and time management, taxes, promotion, marketing, etc., etc., etc.) before you go there, and be very sure you have a product which is as good as you think.

    Don Wilde
    "There's more than one level to any answer."