ElectronJS alternative: SciterJS – HTML/CSS/JS in 4.5 MB executable

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.

Computer systems and network equipment have a fixed install and fixed operational costs. I think the incremental energy cost of transferring 1GB across 5000km is on the order of 1000 Joules of energy. I think 10Gb optical transfer requires less than 10W per 100km... this probably a really high upper limit (equipment electrical power plus cooling power).

1000 J is roughly equal to 0.0003 kWh 1 kWh electrical power generation produces about 200-500g CO2 depending upon the electrical grid.

So that would work out to about 0.15grams per 1GB of data, at the most. The fixed upfront equipment costs and carbon footprint do need to the factored in as well but they are not going to amount to much.

So yeah... we talking about less than a gram of CO2 per 1GB.

I don't care to run the numbers further than this...

Consider that you need add ... element that will implement natively MS Word editing area. This will allow you to define MS Word editing chrome in HTML/CSS but keep core editing functionality native and effective.

Consider implementation of native element/behavior: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

This is a demo of how native code can extend DOM - adding native "drivers" of app specific DOM elements. Yet there are other examples of native behaviors: https://github.com/c-smile/sciter-sdk/tree/master/include/be...

Essentially native behavior can do anything that built-in elements can do, even drawing on the same surface that the rest of DOM is using.

Good luck with achieving anything like that in browsers, or in Electron, or with WebAsm or whatever.