[ksec]

For $100K in total, a tiny marketing budget those companies could have shown some good will towards Open Source.

I wonder if the author actually contacted those companies. That is less than $3K from each of those customers listed.

[gkoberger]

I agree, but companies don't work that way unfortunately. It's really hard to go ask your boss for budget to... just donate.

[pkphilip]

Also since these companies are already using the product and perhaps have even paid a licensing fee or royalty for it, it is unlikely they will want others to get it for free.

Or perhaps not. Perhaps some companies will see the value in getting more people to commit code to this product - which will likely happen if it goes open source.

[artiscode]

Given the author wants to release Sciter under GPL, unless twice as many funds are raised, I fail to see the incentive for any company to fund this. GPL + commercial licensing model changes nothing for commercial product developers.

[nly]

It would be surprising if the companies using Sciter (Norton, Avast, ESet, BitDefender) didn't have a copy of the source code with their commercial license, and the right to ship their own patched version with their software.

If the project ever fizzled away they would probably just maintain it themselves, or migrate to Electron. Actually, it's not like these AV companies are known for their high quality product, so it wouldn't surprise me if they would just let it bitrot until there are exploitable holes.

[Rebelgecko]

Why is sciter so popular with antivirus companies?

[c-smile]

For many reasons.

Compact and manageable UI layer is the first. Full Sciter build for one platform/target is 50 seconds or less. Electron/Chromium builds are about tens of hours as I've been told.

Yet this https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...

is the same app that uses the same UI engine since 2007.

UI maintenance all these years is the matter of updating CSS declarations. Yet you always know that it will be HTML/CSS people that can do your UI in future.

[webmaven]

> For many reasons.

[snip reasons]

But why AV companies specifically?

[c-smile]

> AV companies specifically ...

AV/security specific reasons:

First serious customer was Symantec with their Norton Antivirus. Norton AV 2007 was their first version that used Sciter (named HTMLayout then). And Norton AV was market leader at that time.

Symantec did first security audit of Sciter source code.

You (AV vendor) have UI engine that fits most of UI requirements (lightweight, supports i18n by nature, flexible to screen resolution, HTML/CSS is well known in UI) and, which is most valuable, secure. So decision is quite obvious.

Yet, psychological aspect.

AV product must look modern at any time. User may not trust AV app that looks outdated - that rises suspicion that it is not adequate to recent threats - so it must look modern. Therefore ability to modernize UI by CSS without touching anything else (happens at least once per year) is the key requirement. UI systems/frameworks that use designs nailed down to pixel grids are too expensive on the long run in such circumstances.

[donmcronald]

What order are those in? The top left (first one) is the best UI IMO. Lol.

[pwdisswordfish4]

Well Mozilla spends over $50 million year-over-year on non-development costs that have generally proven to be completely ineffective: their marketing budget. So a one-time $100k cost is a fraction of a percent of what they already squander on at least one program they get next to no ROI from; pay the one-time cost for this, and the marketing they get out of being the one that made it happen comes along for free.

And they outwardly profess to be in an uncomfortable position due to Blink's stranglehold over the hearts and minds of developers. Electron plays a major role there. Something like this would go further to support the Mozilla mission than anything they've done themselves (and done to themselves) over the last ~3 years...

[eitland]

> Well Mozilla spends over $50 million year-over-year on non-development costs that have generally proven to be completely ineffective

Warning: opinions and unresearced statements ahead

Considering the contract they landed earlier this year many of us would be really happy to fail so successfully financially.

That said: Of course on the technical side they've given away much of their previously huge edge on extensibility, gained some performance (or so I hear, I never had issues with the old Firefox) and some security (again: from what I hear). Oh, and spent some major goodwill from the security community on stupid gimmicks.

Here's to hoping they can pull something off (for example by sponsoring this project or something, I don't know) to make themselves relevant again and stay relevant by again capturing the power user / enthusiast niche.

Because right now we are starving for better alternatives, there isn't exactly much to be enthusiastic about at the moment IMO: browsers just get more and more complex and enable more and more crazy applications.

[pwdisswordfish4]

> Considering the contract they landed earlier this year many of us would be really happy to fail so successfully financially.

This is worded as if it's a retort to the previous comment, but... how is it supposed to be?

The claim is that Mozilla's marketing program is overbudgeted and useless, not that Mozilla is "financially [un]successful". Even if you subscribe to the philosophy that multi-million royalties -> success, there's no contradiction. The only way that would be a contradiction is if the marketing team is the one that "landed" that deal. (And that deal isn't even new. Mozilla and Google have had similar deals forever.)

[eitland]

> This is worded as if it's a retort to the previous comment, but... how is it supposed to be?

> The claim is that Mozilla's marketing program is overbudgeted and useless

My point was that maybe they are targeting their marketing at someone else than end users (Google? Regulators?).

And that I think it is frustrating and a bad idea in the long run.

[est31]

$200k is still chump change to these companies. Probably Github has paid a multitude to that to the team of employed electron devs already, and that's just for the work of wrapping CEF with a js layer. Sciter on the other hand is an entire HTML engine. As the new evolutionary step beyond electron, I think it deserves that money. Even a million dollars would be still a deal.

[artiscode]

I agree to both that $200k is change for many companies and that it's very well deserved. My point is that companies that use SciterJS for commercial applications already have a commercial license. Therefore releasing Sciter as a FOSS product under GPL license doesn't change anything for both existing and new players in the market.

[bachmeier]

> GPL + commercial licensing model changes nothing for commercial product developers.

I'm not sure I understand your comment. This is an Electron alternative. Is it common for companies to release modified versions of Electron? I admit I don't work in this space, but I thought the point of Electron is to make it possible to distribute a web app as a "native" app. Why would a company dig into the source code and develop a modified version of Electron rather than simply use it as a tool to distribute their app?

[wongarsu]

I would suspect that an app that depends on (and is shipped with) a GPL engine gets contaminated with GPL.

If we were talking about LGPL this wouldn't be a question because of the linking exception, but with the GPL no company would want to risk being forced to release their source code. Anyone with a legal department would opt for the commercial licence

[invaliduser]

Native c/c++ code linking maybe? Linking with native modules may be important to some projects, and that's complicated when the GPL is involved.

[bachmeier]

> Native c/c++ code linking maybe?

Companies do C/C++ linking to Electron itself in a web app? I'm sorry, but I've never heard of such a thing. Do they also do C/C++ linking to the browser for the web app version fo the app? Web development must really have changed in recent years.

[qppo]

> Companies do C/C++ linking to Electron itself in a web app?

That's one of the selling points of Electron, write your frontend in whatever JS framework your frontend devs want to use, provide hooks through node modules to your application where the heavy lifting is done using whatever language/runtime you want.

> Do they also do C/C++ linking to the browser for the web app version fo the app?

If a web version can exists (Electron apps cover spaces that web apps can't), and it's identical to your Electron app, then your Electron app never needed to be written in the first place.

[k3liutZu]

> Companies do C/C++ linking to Electron itself in a web app? I'm sorry, but I've never heard of such a thing.

Yes. Specifically to bridge into native functionality.

> Do they also do C/C++ linking to the browser for the web app version fo the app? Web development must really have changed in recent years.

There might not be a webapp (if the core functionality requires native code). Or it may exist but have a different tech stack involved where the native code can't be used.

[dmitriid]

Those customers probably couldn't care less about open sourcing somebody else's work.