Sponsors have access to the private repository (I'm using GitHub's collaborator feature). I have several sponsor tiers and $10 a month or more will get you access to my sponsorware, which means you will be added to the private repository and can use the features immediately. What you're effectively getting is early access, so you can use the features before other users.
The official documentation of my project lists exactly which features are "Insiders only", and which aren't. When the features tied to the funding goal that was hit are merged, everybody can use them. I try to always have sponsors-only features on higher tiers to keep sponsoring attractive.
As I understand, Caleb does it with content and entire projects - I'm doing it with new features for an existing project. Also, I'm doing it fully transparent, disclosing how much I earn with this, which I think is crucial to build the necessary trust relationship.
This is indeed a problem. However, given that you need to pay for a subscription to get access, I consider the risk rather low. The Insiders code is released under the same license (MIT), as I didn't want to make things complicated, so I couldn't even enforce someone publishing it. I have a fair-use policy [1] that (up to now) all users respect.
Yes, the model is far from being perfect, but it allows me to pay at least some of my bills. I'm always curious to learn how to improve it!
I suppose it's licensed under a non open source license until it's released to the public. If so, you can prosecute such individuals who break the license.
It's MIT-licensed, as the original project. I have no interest in legal prosecution. Also, different licensing would make it more complicated for companies.
> different licensing would make it more complicated for companies
True, although just removing a couple of words from the MIT license would still be a very attractive and easy to use license. Examples of words you might remove: "sell" and "sublicense".
Remaining open source but banning the user who leaks the source code from the repository could work too, no? (the RedHat way).
So as a user, you can start some work based on the insider version and be confident that you will be able to release your work even if the insider version never goes public for some reason, instead of relying on a promise that the code will be released in an open source license.
The official documentation of my project lists exactly which features are "Insiders only", and which aren't. When the features tied to the funding goal that was hit are merged, everybody can use them. I try to always have sponsors-only features on higher tiers to keep sponsoring attractive.
As I understand, Caleb does it with content and entire projects - I'm doing it with new features for an existing project. Also, I'm doing it fully transparent, disclosing how much I earn with this, which I think is crucial to build the necessary trust relationship.