> What would be strategies in case of Kickstarter campaign will fail? I think you chose the wrong goal here. I don't think you really want a one-time, lump su

> What would be strategies in case of Kickstarter campaign will fail? I think you chose the wrong goal here. I don't think you really want a one-time, lump sum donation to "unlock" your code under a FOSS license. I would think you want regular, recurring payments to keep you in the job of writing the code that pushes the project forward. Judging from the cron job of "Electron-so-fat" posts here on HN, there may be an audience for that. And judging from the fact that you've already raised close to $10,000 to unlock the initial code, unlocking code may be a sufficient incentive to get that audience to pay you to do the work. But to keep that number up for recurring payments I think you've got to keep on the "Farmville" route, at least if you want to get paid anywhere near the going rate. That is, there needs to be a risk not only that you abandon the project if you don't get paid, but something the audience cares about will quickly die if the payment goals aren't met. You're kind of doing that here with the MIT license being a kind of "stretch" goal, but I think you could do it more effectively on a recurring basis with the code itself. AFAICT you can achieve the following approach with either choice of the MIT or GPL (either version). That is: 1. you work on the next feature in private 2. get it ready for a release 3. release a video of you demo'ing the feature 4. if your recurring payment goal gets met for this period, you commit the feature to the public repo 5. if not, you delete it This complies with both licenses-- there is no requirement in either to share the source code for a binary that you haven't released yet. I will admit it is seems strange, as there's a chance you'll have to delete useful code if the goals aren't met. But if you don't take that approach you risk continuing to develop a project for an audience that isn't willing to pay the going rate. That, and the burnout that it causes, is a much bigger problem than my suggested approach could ever be. Besides, this is how most businesses work anyway. No drive through is handing out the food first and collecting the money second.