> What would be strategies in case of Kickstarter campaign will fail?

Publish under GPL and don't listen to those who tell you that "open source" means anything other than offering your code to folks under an open source license. Just do whatever you're already doing right now, chuck code over the wall every now and then with an appropriate license attached, and ignore anyone who isn't paying you but insists that you owe them something.

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.

I have seen systems too where every new feature to an open source project had to be sponsored by big companies. If nobody is paying for it, it will never happen.

Right. That's the GhostScript funding model.

That's precisely what I did with Sciter development all these years.

"3. release a video of you demo'ing the feature"

That's what the Kickstarter campaign is all about.

"5. if not, you delete it"

Yep :)

Revenue streams ideas: 1. Build a deployment tool, where you take care of building the apps for the different OS, basically bridge the gap from code to final binary 2. Offer support / consulting hours "from the experts" 3. Force some kind of ad/watermark/screen on the app where you can see the name of the project and website. In order to remove this you will need a key or build the project using the service I described in point 1.

Happy to chat and discuss in more details. Good luck!

Say you would need to support 2-3 members team of highly professional software developers... Is patreon realistic for that?

Both Patreon and Kickstarter is oriented towards consumer goods but Sciter is a B2B product. Software-wise people use Kickstarter and Patreon for consumer goods like games where you need literally thousands of fans to be profitable.

Sciter is a really good quality software and I believe it can overtake QT in future, but I got a feeling you might want to go with VC funding and possibly change the business model.

I was thinking about something like that. But again, realistically speaking, what would be interesting for VCs in such project to even bother about it?

Do you think market(consumers) for GUI design software will increase or decrease in future? I do believe it will increase as more and more companies need in-house software. Also, it is worth noting QT has ~60 million dollars in revenue and that is definitely in the ballpark of VC backed money. You would probably have to deliver 10 million on a 1 million investment.

It mostly boils down to marketing and some quality of life improvements. Do you got a sales staff? Again, I'm in the gamedev business so I got no deep-down knowledge about GUI designer market but marketing costs are about 100% of development costs for desktop games (at the very very low end) and up to 1000% of development cost for mobile games. So in game development, marketing is the bulk of the cost, and development costs aren't all that important.

What do you think marketing costs are for GUI designers, or do you know how much QT spends on that? As an user I feel like Sciter is lacking good marketing at this stage but you can only know that and chart your way.

Please don't take any of the above advice too seriously because again I'm just a game developer, you will have to figure out this stuff yourself.

In regard of this, there are three types of consumer roles:

1. "readers" - all of us reading the internet, e.g. me and you reading HN now.

2. "creators" - all of us who create IT stuff and content at some extent- sites and content, browsers will never be quite adequate for that role, for many reasons. Compare desktop Word and those desperate and ugly attempts to reproduce it for browsers.

3. "app users" - you or me consuming modern applications, Slack, Skype, etc. That must be lightweight desktop apps, IMO. Sciter.JS (as does Sciter) is the best candidate for such cases.

Groups #2 and #3 are smaller but proportional to #1. As soon as #1 will grow as #2 and #3 will grow too.

So the need for desktop UI will definitely not go away in foreseeable future - only grow. And so the need of HTML/CSS in UI too - due to flexibility of Web stack and developers base.

See Evan You (Vue.js) for example: https://www.patreon.com/evanyou

You probably need to be in the right niche for this model to work, I'd suspect it is quite hard to pull this off. But that goes for most ways to get paid for open source.

Finding a way to fund this is going to be an uphill battle, although I like the creative ideas amadeuspagel mentioned. Like anything else, find a niche somewhere (possibly related to performance/memory for clients not using React) and serve it with a modest upsell. But it's an enormous market, with entrenched competitors who don't need to make a profit on their offerings, so expect fierce competition all the way.

As an open-source developer where I am not thinking to earn a single penny from apps I build why would I support the Kickstarter campaign and as a Company who want to make big why I would I support the campaign to open source it where I could just buy the source code if I want to and get an edge over others.

For obtaining revenue and building a community their model works well. Just not an open source community.

Unity is free for people and companies to use if their revenue is <$100k/year, so lots of people use it for personal projects and as early stage businesses. That gets them hooked and happy to use it, and builds a community of 3rd party add-ons and assets.

For any business whose revenue then grows to > $100k/year, the business can easily afford the relatively low license fee of Unity; they won't mind. That fee goes up with increasing revenue of the business.

BTW: Sciter already works inside Unreal Engine pipeline as plugin: https://sciter.com/see-sciter-lite-unreal-engine-in-theaters...

The Unity and Unreal models aren't open source, so if you want open source as a feature, as well as revenue, you can't quite copy their models.

To get open source together with revenue, you'd need to use one of the open source business model approaches.

One of those models is "open core" where the core product is open source, and there are additional features for pay which aren't.

Another model is to use GPL or a similar copyleft license for free, and require a license fee for a more open license. Qt is a well known product that uses this (qt.io), and they also offer a revenue-based discount so that smaller businesses can pay less.