Technically, the compiled source published to NPM is MIT licensed (it's minified JS), and the end-user can reverse-engineer it however they like. MIT license does not mean human-readable source afaik :p
^ j/k fyi, since your comment sounded serious so I just wanted to ease the tension. We're planning to open-source the repo, but ATM we have not set up everything to welcome the community yet (CoC, contribution guideline, CI for testing, issue templates, etc...)
BTW, love your passion for open-source and appreciate the criticism (esp your effort in taking a deep look at the stuff we are building). The NPM page is nowhere ready for public view yet. The thought of slapping the TOS and Privacy Policy in the readme is so that if the user installed our CLI and managed to initiate some of the extra undocumented capability, we wouldn't be responsible for any damage to their hardware. But perhaps the MIT license should suffice for that case?
On the other hand, I am asking for feedback on the documentation, so if we can stay on that topic that would be much appreciated :D
My problem with this is that you are asking us for free review of a tool that you claim is MIT, while you are actually keeping the source closed.
Surely you can see the problem with that.
You are also vastly misrepresenting the contents of your ToS here, which actually contain a binding arbitration clause and this unbelievable gem: "you agree not to [...] disparage, tarnish, or otherwise harm, in our opinion, us and/or the SERVICE"
> you claim is MIT, while you are actually keeping the source closed.
I do not get your argument. The MIT license is not a consumer-right protection license, it is a license made to protect us, developers, from having to deal with hostile actors. Nowhere in the license does it says the developer is required or responsible for disclosing the source in a human-readable form. It simply says the user can use it for free, that the developer is not responsible and there is no warranty.
> this unbelievable gem
Why is it an unbelievable gem? I do not see why it is different from MIT's "IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."? Also, thanks for parsing thru the TOS - I created it from a template, thus haven't gotten around to actually making sure it makes sense (i.e a TOS is made to protect me and my company so it made sense to me to just keep anything that would prevent legal trouble).
A better overview of like what browsers and maybe some more general project information. and it isnt very responsive FF iOS. Looks cool, maybe add like "cordova for browser extensions" or something more accurate tagline.
I see - I was debating whether it would be cool to reference another project in our documentation. I would say what we are creating is like "NextJS for browser extension development"
I’d like to get feedback on the documentation we wrote for our browser extension framework. Anything to add or remove? Are there sections that are too confusing or unclear?
You should put what the requirements are up-front. Only after reading through the file-structure did I understand that your plugin assumes both React and TypeScript is being used for building the extension.
It'd be great if the documentation could start with showing how is different from the many other similar solutions that came before you, to make users understand the value proposition of your framework a bit better.
I went to the main-page to see what the main product you were building, and seems the browser extension framework is the main product. I'm not sure if the Pricing is placeholder pricing or not, but $256 per user per month sounds like a lot for a extension framework, but maybe I'm not the target audience, I've only published a few browser extensions as an individual.
It is indeed placeholder pricing - I am not entirely sure how to structure this business yet, really wanted to lean toward an open-source model with premium support (hence the 256 pricing tag on premium support).
The framework itself is free. Only if the user require hands-on contracting work (i.e, a demo of integrating with their in-house framework) would it trigger the support price.
Your feedback indicates I should separate the "enterprise-support" pricing from the "Developer" or Team pricing, and also make it less expensive (certainly lower than $256). Since the base framework is free (like Next.JS), how much would you as a solo developer pay for a feature that allows you to test your extension without having to submit and wait for the chrome/edge webstore review?