How To Monetise?

[jezzsantos]

When the code template is nearing its completed state, it will represent significant value to those who wish to use it. Estimates (from past initatives), put the codebase at about 70,000 LOC. Which coarsely equates to about 700-7000 days of work (depending on your measure of production lines of code per day (10 LOC/day -100LOC/day). Conservatively, that's ~2 years of work, that you would have to spend achieving a similar outcome, if you started from scratch.

Caveat, albeit many of the available components, specifically some of the technology adapters included in this codebase, may never be used, and can be deducted from that estimate.

Thus, an appropriate financial contribution could be accepted by the buyer for the time saving to their business.

This contribution (in whatever form) would ideally be a one-off amount (rather than recurring), and it could also be per usage (i.e. per product used).

The code template, in its entire form, would need to remain available (open-sourced) to browse and examine by the buyer. This is believed to be necessary in order to feel confident judging its value, and in purchasing it.

It would also need to be licensed, (e.g. Unlicensed or MIT), such that ALL rights are transferrable to the buyer, to do as they please, with no limitations.

However, being fully available (to browse), presents a challenge in collecting contributions, since those obtaining it can easily do that without incurring any contribution back. There is no mechanism in this platform to help with that.

Option 1: Fully open source it

1. We open-source the repo (make it public), and spend time and money on marketing it.
2. We only ask for sponsors or for voluntary financial contributions

Expectations:

• Interested people download and use it. Maybe it can get some popularity?
• Few are likely to pay any financial contribution

Cons:

• $0 revenue
• Possibility of sponsors? unlikely
• Only fans and the occasional hero would be engaged in making it better

Option 2: Make it a standard paid-for-product

1. We keep the code hidden (private repo)
2. We provide an open-source license to the codebase (MIT)
3. We expose code snippets and the like, to demonstrate its patterns
4. We create a landing page with demos, and videos and the like
5. We license it per instance with a license to use on 1 software product only (something like ~USD$150 per instance)

Expectations:

• $ revenue
• Less uptake, as it si harder to see the value (before buying)
• Probability of no sponsors?
• Buyers now engaged in helping to improve it (since they paid for it), and will expect support

Cons:

• Possibility of buyers then ripping it off and open-sourcing it themselves
• No way to enforce repeated charges (for extra uses) we may only ever get one fee per buyer
• They will require a private forum and service to support it moving forward

Option 3: Open source it with dual license

1. We apply dual licenses to the repo (MIT + Other)
2. We share all the source, except one small nuget component that is critically included in each runtime host.
3. This component is closed-sourced and possibly (obfuscated) and published to nuget.
4. This component can verify a license key that must be available to the runtime
5. Code for the nuget is kept in a private repo.
6. To get a license key, customers pay a one-time fee for it. Let's say USD150 (for argument's sake) for an eternal license for that person to use for that product (or for any number of projects), we could even have two fees (one per product, one fee for any number of products).

Expectations:

• $ revenue
• Risk of buyer hesitation because of open source principles and the license fee
• Possibility of reverse engineering the nuget, and working around the license fee

Cons:

• Possibility of buyers then ripping it off and open-sourcing it themselves
• They will require a private forum and service to support it moving forward

[jezzsantos]

If we select Option 3, then the private nuget could contain the source generator we have for converting API definitions into minimal API and MediatR handlers, plus a few other components needed in that call stack at runtime.

Without this component, some key interfaces would be missing in the open source.

If a savvy developer were to try and work around having that component included in their copy of the software, the author could remove it, and do their own wiring up.

The only reasonable mitigation to this (apart from putting something into the dual-license, is to make that harder to do than the cost of the license. If the cost was reasonably small like USD150, they perhaps would not bother. If the cost was higher, they may invest the time, as it will be seen as a technical challenge to please their paymasters.

Strategies for enforcement

With the component in the runtime, we could do a few things, depending on the strategy.

We could fail the runtime if the license key is invalid, for any number of reasons.

For example:

• We could, only look for a license key if NOT TESTINGONLY.
• We could only look for a license key if NOT TESTINGONLY, and if there are any API's over and above the ones included in the base template.
• We could call home, if NOT TESTINGONLY, with the license key and some unique attribute about the deployment. (i.e. its public URL, or IP Address), and ensure that the runtime is not running at the same time as another instance with a different URL/IP address.
• others?

[jezzsantos]

Plan of Action

Stage 1

During the development of the web framework patterns, the code is changing rapidly. We leave all the code in the repository, in the open.

Stage 2

Once the patterns have stabilized, perhaps after we have some feedback from other developers on their look and feel. We move some of the components (e.g. Source Generators and extension methods) to a private repo, and remove them from the code base. We publish that nuget and take a dependency on it from that point. No license checking or anything, At this point we change the license of the main repo to be dual license and start accepting sponsorships.

Stage 3

We announce that we are charging for future uses, and start checking for license keys.

Beyond that we can get a little more creative about the checks and limitations.

[kzu]

If the package is not OSS and obfuscated, it doesn't even need to be a source generator, a plain library would be enough (unless you use code generation to make it better).

The three stages, unless the first is OSS, how do you envision folks adopting it? It seems like a "bait & switch" approach to get them to use the codebase and then changing the licensing to monetize. I doubt this will be well received.

[jezzsantos]

@kzu Yeah agreed. The source generator is currently a vital part of the API layer, and there will be other parts emerging soon. Just did not want to put too much in that package that cannot be seen by the users of the codebase.

So i am telling myself that there is some kind of balance to strike in what goes in it. I think it would need some base types (or other things) from the domain layer for it to be effective enough (can skip the Application layer). Im also investing heavily in providing a few Roslyn analysers to enforce dependency directions and vertical coupling, so they can go there too.

The trick will be striking a balance with having enough in it to prevent someone removing the dependency on this package and reverse engineering what it provides. Versus only just enough not to have to see it.

About the bait and switch. Definitely not the intention.

Right now, I believe that the repo (as a useful whole) does not have any value. I will mark it PreRelease to make that clear.

At some point that will change, is the intention. So part two and three need to happen before that point, and I think Ill need to do a good job of being transparent about what it is and why it is there to mitigate the critics.

Given that there is much to do before this really matters, do you think I need to do anything sooner than later?

[kzu]

Reverse engineering of what's happening is pretty much guaranteed. Emitting source generated files for inspection (and therefore copying) Is supported OOB by Roslyn, so that doesn't add a hard layer to overcome.

Perhaps the annoyance is just enough to make the customer pause and think whether they are OK with the legal risk, but that's about as much guarantee you can have, IMHO.

[jezzsantos]

Yeah, I cannot disagree with any of that. Sadly its true.

The way I am thinking about it is this at the moment:

• Our TAM buyers are those founding developers/statup CTO's who are starting a new business, where money is tight, and savings in time is paramount to them. That is the only audience this offering makes sense to (that we know about today at least)
• Some of those developers will never want to pay for anything. They've probably had it easy their entire careers with someone else footing the bill for all their tools, and they've never paid for/sponsored/contributed to open source. When faced with it, they will try and explore workarounds to avoid any payment no matter how much that makes sense economically to their time, or to the rest of us ethically. Some are curious, some are just outright devious, and ungrateful. Nothing we can really do about that at the end of the day. I expect that will happen to some proportion of consumers. As long as that proportion is small (and the set is large enough), it maybe still financially viable.
• Some of those developers will either respect license terms, or see the value they are getting, and will see no problem paying the asking price tag (as long as it is not unreasonable to them). I am thinking that maybe a couple hundred USD (at the lower end) will just pay it and go, as long as they see clear the value. (one-off payment)
• A low price should also help increase adoption (and reputation), certainly in the earlier phases.

So I think it's a balance to strike. I see no foolproof way, and no certainty in a any direction.

Do you think its worth moving forward with that set of assumptions?

[kzu]

Yeah, that sounds like the best course of action. I'm usually more in favor of recurring revenue to ensure the project can continue evolving over time, without having to resort to adding never-ending "features" just to entice users to pay for upgrades (like Office used to before the subscription model).