Founder of Streak (author of the InboxSDK) here. Yes we made the difficult choice to close source this. One of the big value props of the SDK is that it automatically maintains compatibility with Gmail and all other extensions using the SDK.
The way we ensure this is by remote loading most of the SDK from our servers to ensure users are on the latest version of the SDK.
One thing we wanted to prevent was developers including the stock SDK directly in the extension or even forking their own version and including it in their extension because then we can't guarantee it will always be compatible with other extensions or Gmail. We'd have to rely on developers constantly upgrading their dependency on us and submitting an extension update to the chrome store.
There are ways where we can still host the SDK but open source it so people can contribute/inspect the code - we just haven't gotten there yet but it is part of our plans.
> one thing we wanted to prevent was developers including the stock SDK directly in the extension
(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.
It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.
