do you have a github repo? if not, why did you choose to self host?
edit: ok, sorry I missed the whole section of your website that answers this. let me rephrase as, "can you say more about why you chose not to open source?"
There is a github repo for the project, it's just private still.
I don't have any real experience with open sourcing projects outside releasing a few small things with MIT licenses (none of which had any real activity from others)—so while there's a good chance I will open source this, I just don't know at this point if there are things I need to take into consideration that I'm unaware of. Hoping to get some feedback on that by posting now.
Edit: haha, okay, answering the revised question:
It's roughly the same thing: lack of knowledge of how open source projects 'work'. I guess I have a number of probably unfounded paranoid concerns about what would happen if I were to open source—which I'm actually less concerned about now, but early on I had some ideas about turning the software into a business, and I've had the perception that you need to know what you're doing to run a business around an open source software product.
* Would it bother you if someone used your code in a proprietary product without paying you? Without even crediting you?
* Would it bother you if someone ran a proprietary web service using your code?
* Would it bother you if someone openly forked your project? What if they ended up receiving donations to work on their fork, while you weren't making anything off of the original project?
* Do you care if a fork (or patched distribution) uses your project name? Some projects trademark in order to prevent this (ex Firefox, Rust, ...).
Related to the above, carefully consider the different implications between licensing under AGPL, GPL, MPL, and MIT style licenses. Bear in mind that AGPL and GPL will significantly reduce the set of circumstances under which someone in industry would be able to use your code - that might or might not be desirable to you.
(Aside: My preference is generally towards MPL, but MIT has its use cases.)
> I've had the perception that you need to know what you're doing to run a business around an open source software product
That's complicated, and likely depends a lot on what _sort_ of business you want to run. You reveal some or all of your trade secrets, but might gain any of visibility, good will, and community contributions.
If you aim to sell a proprietary product (as opposed to consulting or something else), be careful under what terms you accept contributions from the community to (a portion of?) your code base. Appropriate modularization of the project is likely to be important in this case.
You hold the copyright to code you write by default (at least in the US). So you could choose to license it to the public under (for example) GPLv3 and you would still hold the copyright - others just have permission to use it in accordance with your terms.
In particular, for the GPL example that means you could still release a proprietary product based on a modified (closed source) version of it. Other people can't, but you can.
It gets complicated as soon as you accept community contributions into your version though. By default, each contributor holds the copyright to their work - you merely have their permission to use that portion of the project under the terms of the project's license. If the project itself is MIT licensed, I struggle to imagine how this could pose a problem. But for GPL, MPL, and similar, you lose the ability to release closed source variants if they would make use of those community contributions.
Some projects require all contributors to sign a CLA granting them copyright (or similar) to avoid such issues. I suspect this would be unpopular, and would likely result in a fork if you aren't a large corporation throwing a huge amount of resources at the project.
Other thoughts:
* Properly modularizing things mostly sidesteps this. Cleanly separate the proprietary portion and release the shared part under a license that allows linking to it (LGPL, MPL, or equivalent).
* If you don't have a clear business plan or the time available to work on this, you might consider just throwing it into the wild in the hopes that your past effort is useful to someone else. That's arguably better than having sunk time into something that never sees the light of day. To that end, something like CC0 or zlib would maximize the chance it gets used.
* Some licenses might not be compatible with certain distribution channels. For example, it isn't entirely clear to me if GPL and LGPL code can be legally used on Apple's app store since the end user can't realistically make use of a recompiled or relinked program on their device.
* Not actually owning all of the code in your product might (or might not) impact your ability to convince someone to buy your company if that's what you're aiming for.
I'm willing to volun-tribute my time to play MITM between you and GOOG queries to do the grunt work in researching options in how best to open this thing up.
I've got some big plans that I am hoping to get my employer on board with so I can finally make my first attempt at spinning up my current variation of the always just out of reach, Tantalus's unicorn.
Not sure if my contact is retrievable thru my public HN acct bits. If not, I'll check back here and provide if there's interest in at least shooting the shinola with another like mind for a minute.
this product looks interesting. just my unsolicited opinion, but if your goals are wide adoption and/or monetization you're probably better off open sourcing this. I can't say how useful it is or isn't without playing with it on my projects. but if it's as good as it looks and easy to use, you'll see stars on github and that will open up a lot of options
edit: ok, sorry I missed the whole section of your website that answers this. let me rephrase as, "can you say more about why you chose not to open source?"