"they're near impossible to monetize "... I would not say so. => Our UI (test) automation/RPA software consists of a totally free open-source extension for web automation plus a paid cross-platform binary file that adds additional desktop automation features. It communicates with the extension itself via native messaging.
The add-on module is available in a limited free and paid fully featured version. It is the classical freemium model, which works well for both, the extension creators and the users.
Another good example of a freemium browser extension is Grammarly. Browser extension certainly can be monetized in an ethical way. (Note: I never used Grammarly myself, just seen the many ads)
Per Grammarly's Privacy Policy, they collect a bunch of data, which includes "all text, documents, or other content or information uploaded, entered, or otherwise transmitted by you in connection with your use of Grammarly’s Services and/or Software. This would include, for example, text you write while using a Grammarly product, such as the browser extension or the mobile keyboard".
There's also:
"You can remove your Personal Data from Grammarly at any time by deleting your account as described above. However, we may keep some of your Personal Data for as long as reasonably necessary for our legitimate business interests"
Very nice idea. As an ISV with a freemium open-source extension, I would happily pay for an official security review that I could present to our users. Our extension is secure by design but having a 3rd-party expert (e. g. Google or Firefox reviewer) confirm this and get a "Reviewed" badge would be great. The drawback is that this could slow down extension updates, as you do not want to loose this badge with the next update. But that is manageable.
Just to mention a real life use case: We are using WebAssembly for the image recognition features in our Visual UI Testing browser extension "Kantu". Before switching to WA, we tested many other approaches, including WebGL (old demo here: https://a9t9.com/demo/templatematching.js/ ).
Whatever we tried before, it was either too slow (pure Javascript), too unreliable (WebGL) or required 3rd party installations (C++). Finally, switching to WebAssembly solved all these problems.
Interesting that WebAssembly could have such a big impact on the viability of the web version of your product! How much faster was WebAssembly than JavaScript for your Kantu tests? Were the WebGL issues because not all uses had WebGL enabled or because of GPU-specific quirks?
Our initial tests were with standard template matching algorithms. With the Javavscript implementation we were stuck in the 60 seconds+ range per image search.
With WebGL it was ~0.5s on a "good" machine and ~6s or "did not work at all" on a "bad" machine. We never figured out why it worked well on one machine, but not so on others. Of course, I am talking only about machines with WebGL enabled ;) This would have been a support nightmare.
With WebAssembly we are now in the 0.1-0.5s range per image search and it just works. So far, we have had exactly 0 WA-related support issues, for both, Chrome and Firefox.
I am not the op, but (faster) WebAssembly could turn out to be a big thing for browser extensions. For example, we are just in the process of adding WebAssembly powered image search to our Kantu Selenium IDE to allow for visual testing. We tried before with normal Javascript and even WebGL, but both results were not usable for various reasons. The websight page gave us new hope ;-) https://websightjs.com/
Faster WebAssembly isn't listed on the roadmap, so you are disappointed, right?
Wasm is currently considered "around half as fast as native"[0]. The Wasm design, Emscripten compiler, and browser compilers all have a part of responsibility in this, but I suspect that browser compilers have the largest share. Mozilla created The WebAssembly Explorer[1] which shows good-looking ".wat", but bloated "Firefox x86 Assembly" compared to "LLVM x86 Assembly". I hope they intend to use this tool to improve Firefox x86 Assembly.
Agree - startup alley is not the place to meet (non startup) customers.
I have been to Startup Alley once with my previous company. We managed to get exactly 0 new customers out of it. So on this point, totally agree with you. I did not expect tons of new business, but not getting a single new customer was disappointing, especially since the product sold well otherwise.
However, I got a surprising amount of good discussions out of it, both at the booth and over lunch. And I had fun. So overall, it was worth the price if you factor in the inspirational component.
Another Jekyll advantage: Jekyll it makes it easy to host a blog under your main domain.com/blog, without the need to use a subdomain, without the need to fiddle with Wordpress and without the need to switch your whole website to a (new) CMS. This is a huge timesaver (We use it at https://a9t9.com/blog and a very happy with it.)
3 months seems long. We ported our Copyfish extension to Firefox recently, and the approval process took only ~10 days. I think first feedback took about a week. The reviewer replied with constructive feedback and we had to change a few small things. Then it took another 1-2 days for the final approval. So yes, there is a real human being behind it. Or some super-AI ;)
Maybe the issue is that GP posted so many as once the they got flagged as possibly being spam/malicious/other desirable thing and therefore got put into a manual-verification bucket?
Extension can/could read all data that you enter in websites. So you should only install extensions from trusted sources/developers.
And/or: What I do is to have one Chrome profile for important websites (e. g. online banking) and another one for the casual web surfing. This "casual" profile is where I try out all new extensions. And only the ones I really need are used in the "secure" profile as well.
"Freemium is a harder model to implement in open source, since the source is, well, open, but we do see this in things like WordPress...."
=> Just to add another flavor: The Freemium model is working well for us even so we are not SaaS.
In our case, the main part of the RPA software is open-source (GPL) and free. All Internet access is only done within the open-source core.
The features of this core app can be extended by local native apps for Mac, Linux and Windows. These are proprietary/closed source.