I worry about this sort of model because it incentivizes you to poorly document your code, or alternatively, it breaks down if someone else documents your code well.
For instance - if there's a particularly tricky way to do something, and you release a sponsor-only video or post explaining it, and then one of your sponsors sees a question about the same topic on StackOverflow and explains it in their own words (StackOverflow already prohibits linking to external explanations without including an answer in-line), would you feel like that is unfair to you?
If you publish a performance trick (as demonstrated on this site), and one of your sponsors sends you a PR to improve performance in the common case, would you want to accept it?
As your project grows, more people will ask questions and more people will be building a community around it. If you want to have market exclusivity for answers, you effectively need to prevent that community from growing so that people must go to you.
It might be possible to do this at scale. This is part of Red Hat's business model, for instance: they have a customer-facing knowledge base that isn't public that includes answers to tricky questions. But Red Hat doesn't depend on the secrecy of this knowledge base. Your entire organization can get access to the KB if you buy a single Red Hat license of any type, which costs something like $50/year. And developers at Red Hat would be happy for those problems to get fixed in the upstream projects.
Red Hat's business model is more strongly around support instead of secret documentation, that is, around responses to specific questions instead of restricted-broadcast answers that help everyone. If you're having a problem in production, Red Hat can help you figure it out (as long as you've been paying them for server licenses for all your servers). And the knowledge base mostly exists to deal with the problem of people having limited time - they document something that's broken, but the intent is to actually solve it, not to leave it in the long-term state where it requires reading the KB article.
Now, people have been trying to do smaller-than-Red-Hat-scale support contracts for their OSS for a long while, and it's worked in some cases (e.g., SQLite, Postgres) but not in general. It might be the case that restricted educational material works out better in practice!
For instance - if there's a particularly tricky way to do something, and you release a sponsor-only video or post explaining it, and then one of your sponsors sees a question about the same topic on StackOverflow and explains it in their own words (StackOverflow already prohibits linking to external explanations without including an answer in-line), would you feel like that is unfair to you?
If you publish a performance trick (as demonstrated on this site), and one of your sponsors sends you a PR to improve performance in the common case, would you want to accept it?
As your project grows, more people will ask questions and more people will be building a community around it. If you want to have market exclusivity for answers, you effectively need to prevent that community from growing so that people must go to you.
It might be possible to do this at scale. This is part of Red Hat's business model, for instance: they have a customer-facing knowledge base that isn't public that includes answers to tricky questions. But Red Hat doesn't depend on the secrecy of this knowledge base. Your entire organization can get access to the KB if you buy a single Red Hat license of any type, which costs something like $50/year. And developers at Red Hat would be happy for those problems to get fixed in the upstream projects.
Red Hat's business model is more strongly around support instead of secret documentation, that is, around responses to specific questions instead of restricted-broadcast answers that help everyone. If you're having a problem in production, Red Hat can help you figure it out (as long as you've been paying them for server licenses for all your servers). And the knowledge base mostly exists to deal with the problem of people having limited time - they document something that's broken, but the intent is to actually solve it, not to leave it in the long-term state where it requires reading the KB article.
Now, people have been trying to do smaller-than-Red-Hat-scale support contracts for their OSS for a long while, and it's worked in some cases (e.g., SQLite, Postgres) but not in general. It might be the case that restricted educational material works out better in practice!