Feature Request: APIs for Custom Pack Pricing

Developers Central
1

There are already formulas for accessing created by and modified by, however I’m after formulas coda.* api calls for the following:

  • document visibility: is the document public/published or private (and whether or not the document allows “copy this doc”), eg. coda.isDocumentPublishedAndCopyable()

  • whether or not the document is owned by a maker who is paying for coda, eg. coda.isUserPayingForCoda()

Having this I’ll be able to properly enforce my free for personal public use, and paid for commercial/private use licensing.

4 Likes
2

Let me look into it - might be able to swing something for the first ask with my doc explorer pack

1 Like
3

I know I could use the Coda API for this, however it is important that these are built ins, as they would be implemented in a pack that would already communicate with external apis, so would consume the one external domain limit already.

Turns out having these as formulas is not actually ideal. The ideal would be for them to be coda.* functions that the packs can call, eliminating user intervention.

The entire use case is this:

  • a benjamin billing pack that provides a block inside the featured documents of benjamin’s packs, that calls an api and checks if the logged in user (or their coda organisation) is on a benjamin subscription
    • if not then it says that the user can only use benjamin’s packs for personal and public use, with a link to subscribe
    • if they are a subscriber, then it shows a license key based on their subscription level that they drop into benjamin’s packs
  • inside the other packs by benjamin, packs call this proposed coda.isDocumentPublishedAndCopyable() || coda.isUserPayingForCoda() == false function and if true, then continue with the formula, if it is not, they check for a valid license key, if no valid license key is provided the formula fails with an error enforcing the licensing

The alternative is for all my packs to not communicate with apis directly, but instead via proxies under a domain I control, that way I work around the one domain per pack limit, however this defeats the purpose of such a restriction in the first place.

I guess my alternative would be for the external billing service to authenticate itself with coda, and itself track which packs are in which documents, and implement billing that way, however that inconveniences reciprocal users as it would require even them to authenticate with the billing service and provide license keys despite using the pack according to its license terms.

For the billing terms, I’m planning the following:

  • $1/month license key lasts for a month
  • $10/month license key lasts for a year
  • $100/month license key never expires

License keys only grant access to packs that existed at the time of subscription. So recurring subscriptions grant access to new packs.

If these API calls can be added then I’ll complete this billing solution within October and November, and open-source the whole thing, so others can also use the same billing system.

I’m also planning addon tiers of subscription, such as perks and or special features for packs, such as addon subscriptions to handle the cases of commercial api usage (such as the coingecko api).

2 Likes
4

Hi @balupton - Nice to hear from you again! It is unfortunately the case that it’s quite difficult to build an alternative billing model for Packs at the moment, since our API and SDK don’t expose a lot of key information you’d need. If you own the service the Pack is connecting to then it’s easier, but if you are trying to layer an alternative billing model on top of another service it’s quite challenging (as you discussed).

It may be worth stepping back for a minute to give us some more insight into why you want to create an alternative billing model. We know that our existing Packs billing model (flat fee, per maker, per month) isn’t very flexible, but I’d love to know more about your motivations and how those are reflected in the model you outlined in your last post.

1 Like
5

The free for ‘personal or public’ and paid for ‘commercial or private’ is a matter of inclusivity and reciprocity: the majority of the world has an internet connection yet earns less than american minimum wage, it is unfair and needless that the artificial scarcity of information billing should have their minds starve or for maintainers to go unpaid because of non-reciprocal extend and extinguish strategies, these spoil opportunity. Talk - Eben Moglen - Free and Open Software: Paradigm for a New Intellectual Commons - YouTube

For the other complexities:

  • The CoinGecko pack is dead in the water due to rate limits that can only be overcome with tiered billing for its commercial api; it’s probably not the first or last in this situation
  • I’d like to offer various perks to subscribers who pay more - incorporating external services - such as support retainers and shoutouts in featured documents, readmes, changelogs, newsletters
  • @Vinny_Green suggested tiered usage billing for some of my upcoming packs that have enterprise use cases - which usage tracking occurs within the external services that provide the primary pack functionality
  • An external billing system also enables referral kickbacks which nurtures partnerships between pack developers and pack ambassadors/salesman/evangelists/marketers

All in all, I’ll have a unified (consistent and shared) billing across all my offerings (coda and otherwise), including the hundreds of npm packages of mine that will go dual-license, and some web services I’m working on. It’s just a matter of license enforcement, and improving the abilities to enforce and reciprocate; something the winds are changing on.

Considering the extent of what I wish to accomplish, I’ll probably go with the proxy technique (which also solves the coingecko rate limit issue by itself as I can control per user and shared caching). However, having those API calls certainly offers a better getting started experience.

An initial coda inhouse workaround could be for pack makers to issue coupons that apply a discount. I could set all my packs at the premium price, then have a “email me for a coupon if you genuinely can’t afford it” proposition.

If the contention is about lock-in on pack billing, there is already lock-in on pack functionality, and pack functionality (for the maker and for coda) is the superior value-add. Creators will increasingly stand out by becoming networked tribes on multiple platforms, an area the music industry already succeeds and leads. This is similar to proprietary networking, however on a global stage reciprocity starts with sharing, then to perks of scarcity. I envision each creator tribe having their own billing pack, which generates licenses for their other packs, enabling streamlined in-coda billing for everything the creator can imagine or require. Per-pack builtin billing exposes packs to increased risk of a race to the bottom undercutting; it’s easy to undercut hundreds of individual packs; it’s hard to undercut a tribe, that’s a war, and wars are costly so networking is often easier.

Personally and ultimately, I kind of see Coda and all software and information, as paper. Paper lets me create new qualities. Digital paper scales. Coda is triumphant digital paper. It is our time that ultimately constrains our creative potential, as other resources can be acquired through time. If paper asks me for money, then that is strange. Money manages the scarcity of resources but ultimately is trading time. Directing money away from the arbitrariness of a ‘good already made’ to the ‘scarce resource directly’ achieves future support of the creator in what seems a purer way; of course still inclusive of credit to other scarcity costs; we are physical and virtual beings. The music industry is well on its way in this transition. The trick is always what leverage is enough to complete the animation; the catalysts that change the norm.

3 Likes
6

Another alternative is revenue sharing from coda subscriptions to pack authors based on install counts.

Pros:

  • transparently remedies fairness and reciprocity
  • easiest flow as requires zero action from pack authors and consumers
  • more equitable than other suggestions so far as the barrier to entry on earning from provided utility will not necessitate tribe development

Cons:

  • does not address the more advanced billing requirements (usage tiers, unified perks, referral kickbacks), however by nature those requirements are addons/surplus to this base billing requirement

If this was done, I’d just focus my billing efforts purely on the perks side which is far easier, and skip all the complexity in the OP. It also makes the remaining billing features for Coda easier too, as usage tiers or even referral kickbacks is something Coda could in-house. It seems the optimal avenue for 20% effort and 80% value for both makers and coda for base billing and addon billing.

7

@Eric_Koleda any consideration to the revenue share proposal?

8

HI @balupton - Thanks for the suggestion, let me circulate it with the team. We have something similar in place for published docs, namely our affiliate program:

One potential revenue model we envisioned for partners was:

  1. Create a great Pack (perhaps free).
  2. Create a great template / published doc using that Pack that solves a use case.
  3. Earn affiliate revenue when your doc brings new customers to Coda.
9

In the meantime, I’ll just monetise my packs using the builtin “charge every maker monthly”, as I need the ROI sooner than later; so far none that are using the packs are respecting the pack licenses, so enforced billing needs to commence asap - just need to work with what I have now, then expand on that later.

I just sent in my application via the google form link - hopefully that is still the latest place.

I’d still love to see builtin pricing like:

  • pack bundle pricing; so say a single $5/month gets access to most of my packs
  • pack tier pricing: so certain packs can have multiple tiers of pricing, that unlocks extra functionality/restrictions
  • option to enable use of the pack for free if they aren’t paying for coda
10

That makes sense. This is the form you need to fill out to get access to selling your Pack:

I don’t see an entry for you in the responses though, so perhaps you filled out a different form?

11

def the form I filled in earlier, however perhaps it was under a different url - submitted again

12

I see it now! It should be reviewed within the next day or so.

13

Hi @Eric_Koleda

What about
4. developing a document with content, that is made available in a subscription?
5. Or a document with functionality to be made available to end-users for a subscription?

Are there any plans to support earning revenue in that way?

Regards
Piet

3 Likes
14

Allowing makers to monetize their docs more directly (selling for a flat fee or monthly subscription) is something we’ve talked about, but there aren’t any concrete plans for just yet.

1 Like
15

+1 for tiered billing for packs with API support in the pack SDK to enable checking the customer billed tier. Would enable freemium pack billing in my use case.

Implementatiin-wise would expect this as some ingress from the sdk that hits a Coda authority service which returns facets about the current user. These would probably be exposed to SDK consumers as read properties populated once at runtime, to avoid hitting the service from within the code.

2 Likes
16

Hi Eric

May I Request/ Suggest that enabling the monetization of docs themselves is an important part of the Coda business? The packs are a wonderful idea, but in the end, they re only going to sell if they are used in docs by doc makers.

To run, one needs two legs, both the packs and the docs.

Just another ramble :wink:
Rambling Pete

3 Likes
17

I’ve split out all the sub-suggestions from this thread into their own discreet topics, that way this thread can be kept on the goal of enabling APIs for custom billing.

4 Likes
18

Indeed. 100%.

And by “content” I assume data also.

Presently there are ways to earn revenues for data via Packs. One could also embed monetized content through Packs but this is severely limiting for those who just want to sell words and lack the skills to build code. And, injecting content through formulas is not the same as content in a page.

1 Like