Rev sharing should go app -> platform

[mleveck]

In this post http://daltoncaldwell.com/3rd-party-rev-share Dalton proposes some type of revenue sharing where application developers are given a cut of app.net's user fees base on some concept of how much those apps are "used." This is what I would call platform -> app revenue sharing. I suggest that it would be better to share revenue the other way around - app -> platform.

Dalton clearly notes that it is very hard to come up with a the right concept of "usage." Should it be time, number of posts, etc.? All of these are very imperfect indicators of how much value an app gives to it's users. Is a site that gets me from point A to point B very quickly more valuable, or a site that keeps me hanging around for a long time more valuable? Google was the former, and Yahoo! the latter. However, it wasn't clear that a quick search engine was more valuable than a portal site until users voted with their feet and clicks, and advertisers voted with their money.

Any proxy for value like time, posts, etc. will likely fail to serve a large set of developers, and over-reward another set. It also artificially caps the amount a user can pay to developers at some fraction of the annual subscription rate, when many users might actually gain (and being willing to pay) much more value.

To this end, I think Apple's app model gets one piece largely right. App developers make applications that are valuable to users. Users clearly express how valuable the application is by paying the developer. Because the platform is valuable to the developer, and allowed them to create the product in the first place, the developer gives the platform a cut of their revenue.

This won't solve a lot of problems. App.net will still have to decide what to do about app developers who want to sell users to advertisers in the exact way that App.net has shunned. However, this issue occurs in any app system, regardless of how it implements revenue sharing, or whether it implements it all.

It is also worth noting that as app.net became more inviting to app developers, and app profits increased, the base subscription rate could be lowered, and yet users would still be essentially paying for the platform.

I believe this model would cleanly and efficiently help app developers make valuable tools, and would integrate well with App.net's vision for having a highly federated platform.

[geofft]

My two cents, as someone interested in developing an open-source client: I'm not sure this fits in with the App.net worldview of fairness to third party developers. It seems like it will inevitably incentivize App.net to support paid clients over free ones, since they won't be able to make revenue off free clients, or conversely require that developers of free clients pay more for API access to make up for the missing revenue. I also don't want App.net to treat me as a less valuable developer than a developer of paid clients.

[mleveck]

Geofft that could happen. It is true that App.net could decide discriminate against free apps because they do not generate as much profit, but they don't have to. However, If App.net is the type of service that seeks to squeeze every bit of profit out of users/developers, in which case this whole discussion is moot. They are then also likely to be the type of company that wouldn't just give out a portion of user fees.

However, I do think you bring up a good issue. Good free apps imply that you need some user fees because you need a free but valuable app that drives customers to the service to be valuable to the platform. This means that users need to be valuable.

However, if you charge a large enough user fee, then:

1) All apps that are valuable to users are valuable to the platform. If the app makes the platform attractive to dues paying users, then it is good for the platform's bottom line (unless it uses too many resources, but this still exists and is possibly worse when there is never any extra revenue from apps).

2) The one downside of the app -> platform model would be that a developer who never intended on collecting money from users (such as yourself) will not see any bonus revenue.

3) However, since you didn't need that to incentivize you to build the app, revenue sharing is unnecessary from the platform's point of view. The platform however does have to contend with the fact that not all developers can afford to give away their time for free. And this is where revenue sharing is necessary. It is a tool to incentivize those who need/want money.

[vitgum]

I think the right way to do is the combination of both approaches: (1) platform->app, and (2) app->platform. Basically, the value is offered by the app.net platform both to developers and users. Which means that users are going to want to pay for it. On the other side, app developers are going to get the value out of the platform. And essentially for me as an application developer this value is the following: i can develop my application to bring ADDITIONAL VALUE to the users. Which means that at least in some cases users are willing to pay for this additional value. How this revenue is going to be collected is the other question: (1) either through the means if the platform (like in Apple App Store), or (2) advertising revenue, or via (3) direct sales.

[wedtm]

Why not assign a percentage of the user's fee's BACK to them, and let the user decide who gets paid?

[dquick-freelance]

Concur with @wedtm - it would (a) empower users to support who they choose (b) simplify things for App.net.corporation and (c) feel similar to how Humble Bundle allows users to divide support (although they aren't as granular). Great idea, @wedtm !

[wedtm]

I think it would remove that "burden" from App.net's shoulders as well. App.net can automatically split up your percentage between the top N apps you use the most, or let you decide it manually.

[markwilcox]

I don't understand the original point at all. Users pay for the platform (or are you suggesting they shouldn't?) - apps will create the value that makes more users want to sign up and pay for the platform. Why would apps then pay the platform rather than the other way around?

The brilliant thing about the platform -> app revenue sharing model is that it gets people to pay a subscription for their software, however small that turns out to be per app. This is something people currently only do for a very small minority of apps. There's no need to start with a certain amount of free service for people to trial it, it's pay-as-you-go with a cap - this is exactly the model that got people to start using mobile data in many countries when they didn't want to pay for unlimited plans.

I like the idea proposed by @wedtm but it should be noted that you still need to do a decent job on the automated system because I suspect most people will not bother to go and use the manual over-ride - it'd need updating every month to reflect your usage/preferences.

[JoshBlake]

Bringing in discussion from some alpha threads (https://alpha.app.net/joshblake/post/51266 https://alpha.app.net/joshblake/post/51890 https://alpha.app.net/orian/post/57066)

From the first link, A@josh points out that suppose nytimes.com or another major corporation wants to integrate app.net but also wants a wide user base. They'd want their readers (or in general existing customers) to be able to use app.net for free. I proposed in that case, the corporation could pay app.net to be in a corporate tier, rather than normal dev tier, and their app is available for free to all app.net users.

A@orian pointed out in that case creating an app.net id needs to be free and we may not want a fractured user account system. The vision then becomes this:

Anyone can create an app.net id for free. Alpha (the current low featured twitter clone at alpha.app.net) goes away to be replaced by what I described here https://alpha.app.net/joshblake/post/51890:

I see alpha becoming just: account management (like account.live.com is to Live accounts), dev dashboard, service status, stats like @clint's appnetstats.com, permalinks to all posts, & 3rd party app marketplace. Global stream but no other streams.

There is no first-party application. No twitter clone. Only third party apps, and app.net truly becomes infrastructure like AWS). The app.net website becomes what I describe above but to users it's primarily a 3rd party app marketplace.

Free accounts can only use apps created by a corporate tier account, which would be a new tier above the dev tier, costing something above $1000/year. The perk of the corporate tier is that free users can use their apps, but the trade-off is they get no revenue share. It's really something that only corporations looking for a broad user base and a great API platform to integrate into their brand and existing customers would use.

Paid user accounts (currently $50/year, but maybe it'd go down to about $25/year long term) would be able to use any app, which would include the broad and diverse marketplace of applications created by the dev tier accounts.

The user funnel then becomes:

1. "Do I want to create a free account and use a limited number of corporate apps/website?"
2. "Now that I have an app.net account, do I want to pay $25-50/year in order to get access to the thousands of third party apps and games people are making?"

Step 1 is corporate tier pays app.net. Step 2 adds users pay app.net and app.net pays third party devs based upon usage of excellent apps and games. It has to be made clear to the users that by upgrading their account, they are directly supporting the developers, and the apps in the marketplace are all 100% "free" to paid app.net accounts.

[fields]

@JoshBlake This makes a whole lot of sense to me.

[nitinthewiz]

JoshBlake has laid it out pretty well. By making App.net just infrastructure, we're allowing other social networks to grow on top of it. These social networks can be of two main types - 1. Standalone social networks with their own websites/apps and 2. Social features associated with websites/other services. A good example of 1) is a photo sharing app. People would be able to comment on the app itself, their comments trickling down to the main App.net infrastructure, which is not visible to them.

A good example of 2) is the news websites, blogs and plugins for platforms like Drupal. Based on the use case, if the website/blog wants free users of app.net to be able to access and comment on the site, it'll need to pay more than a usual dev account. Here too, we can add distinction based on usage. A simple website used by no more than 1000 people in a year shouldn't be asked to pay a $1000/year, that fees would be reserved for sites like News Media.

Finally, I agree that paying App.net users should get completely free access to the entire structure, barring only those websites that want to be exclusive. These paid users will be able to open any of these websites, apps or plugins and login with their App.net logins and their data would be displayed immediately. Please note that I did not say 'ported' as App.net will be the ultimate storage for all personal data, thus being able to provide a centralized place where all the users' information is kept and easily accessible and changeable. This is similar to the concept of a centralized account.

Some notes -

1. The users' personal data will be stored in App.net. But, based on type of social network, certain social networks will be allowed to keep certain parts of the user's everyday data on their own servers. For example, a photo sharing site may not send all the pics to app.net, insteading, keeping the pics, just send a link to the original file and the comments associated with that post to App.net. That way, when a third party app goes to the App.net API to access that social network's feed, it is given a link to the image and text based comments associated with it. This will reduce the load on App.net's infrastructure.
2. There will be certain social networks that will want to restrict entry of users. That means that even certain App.net users will not be able to get in. The use case would be some company specific social networks that want to be able to allow their employees to use all of app.net's social features across the Internet but not allow the rest of the Internet to see into their social network. This should be made possible for a fee. This entails a lot of things - The company social network will have an admin who will be able to accept or reject admission to the network. The internal users will still be able to access the rest of App.net's infrastructure, without needing another account for external App.net access. Finally, no matter what happens, App.net should support data secrecy to ensure that no one can misuse the API to access company information.

[JoshBlake]

@fields @nitinthewiz Thanks.

@nitinthewiz On your last point about private, corporate/enterprise social networks, I would think that this could still fit into the dev tier/corporate tier model but using a third-party app plus access control (#33) to create private social network circles. The company could choose whether to pay for user membership for all employees or for a single corporate tier for themselves (smells like an site license to them) based upon whichever works better for the size of the company. The third-party app developer could still license their enterprise client software to the company as a separate transaction.

Also reference: Yammer https://www.yammer.com/about/pricing/

I don't think app.net shouldn't complicate the model too much. They can always add more options for certain niches later, but I think the free/paid user model and dev/corporate developer model works well. Note - when displaying the signup page, do not show all four models to regular users! Look at how Vimeo segments their users http://vimeo.com/join http://vimeo.com/plus and http://vimeo.com/pro

[jschlesser]

Ive had a lot more time to sleep on this and I propose the following scenario, it applies to a wider range of issues than just "who pays" but is critical to user experience outside Alpha on corp integrations.

1. Allow the nytimes.com to have a corp account with sub accounts so for instance my account might be jschlesser@nytimes. This allows nytimes to create accounts and control accounts without sending users to app.net for things like authorization which just wouldnt make sense in that context.
2. Allow users to link their app.net accounts to their corp accounts somehow which would effectively merge the streams but not actually under the hood.. If somebody violated the nytimes spam or trolling rules they could suspend the spammer@nytimes account and if that person had spammer@nytimes linked to their @boris_and_natasha account, nytimes could sever that link. If nytimes is paying for spammer@nytimes that makes sense and it allows @boris_and_natasha to continue to troll around #cartoonvillian in Alpha if they want, or wherever they are welcome. Getting back into nytimes is between nytimes and boris_and_natasha.
3. Lets say jschlesser@nytimes is also jschlesser@wsj . those stay separate till jschlesser creates an app.net account (josh, thats me) and merges them.
4. If I already have an app.net account i should be able to just use my app.net account @josh at nytimes and wsj and get all the benefits of a consolidated account, plus free apps etc... In this case, nytimes wouldnt have to pay for my account but could still break the link between nytimes and josh if they needed to (kicking me out because I hang with boris and natasha, lets say, instead of moose and squirrel).

Start poking holes.

On Aug 14, 2012, at 11:23 PM, Adam Fields wrote:

@JoshBlake This makes a whole lot of sense to me.

— Reply to this email directly or view it on GitHub.

[orianmarx]

When I think about this, I always try to start with the premise that App.net is an infrastructure company. As such, when it comes to how they should be pricing things, it should be a reflection on utilization of the infrastructure. It might seem hard to figure out how to determine utilization, but if App.net can't figure that out then they shouldn't be in the infrastructure business (for one thing, I don't think figuring out utilization is that hard and for another, I think the App.net is very capable of doing it).

Now, lets take an example of NYTimes and say it wants to build a service whereby people can sign up to receive a notification when the times publishes a new post. That's all it does. Now lets take another service that is a network of surgeons, and the purpose of the service is to share videos of procedures being performed and share notes on these procedures.

The Times example might be a very large network of users that ends up consuming a relatively small amount of bandwidth. The utility cost for this should be low, and the NYTimes can simply pay for it out of their marketing budget. They should be able to choose to make this service free to users if they want.

The surgeon example might be a very small network that consumes a lot of bandwidth (let's make the assumption that app.net is hosting the video files). Here the utility costs would be high, but it's likely these surgeons would also be willing to pay a high fee for membership in this private network.

In either case, App.net makes its profit as a utility provider. To me the two big questions are a) is the Times essentially prevented from offering a free service that they subsidize due to the fact that there is a base membership fee for all users of App.net currently and b) should App.net make an additional profit from high-value networks like the surgeon one by charging a percentage cut of any services' revenue.

I think App.net will have to move in the direction of as close to zero base membership fee as possible, to get access to the market of services. I think they could take a cut of service revenue, like Apple does, but I think it's likely that they shouldn't. Consider that App.net has to build its userbase concurrently with its market. That was not the case for Apple. They had the userbase by selling the iPhone. I think developers should be rewarded for coming up with ideas that result in services that people perceive are way more valuable than the underlying infrastructure cost to operate with them. That's known as building a high margin business. If you can do that, more power to you.

[orianmarx]

Here's a slightly different way to think about it. In the Apple example, you need to buy an iPhone before you can run any iPhone apps. Right now on App.net you need to buy an account to get access to any App.net apps. The iPhone has a base amount of utility even without any apps. Does App.net? At the moment it does because we've got Alpha. But Dalton is considering shutting that down. Even if he doesn't and Alpha continues to be a wonderful an useful service, the important thing to realize is that the scenario is that we're really paying $50 because of the utility of Alpha at the moment, not App.net (or we're paying it because of belief in a future vision, etc).

Rephrasing slightly again. Let's say Apple never built the iPhone and just built an app store for web startups. The premise was "we've put together a lovely place for you to discover web startups to sign up for". Would you pay $50 to access that?

[mleveck]

Everyone who has proposed that app makers primarily get paid via a cut of user fees, please address the question that dalton originally raised, and led to my initial proposal:

What fair and efficient metric would you use to divy up the proceeds? Please make sure the payments would accurately reflect the value received by users.

Time used, posts made, number of users etc. are all highly gameable. They also will not reward high value apps that have a niche market.

Having users simply divy up their own account funds also seems like a horrible idea. 1) It puts app developers at the mercy of potentially lazy users 2) It is ripe for making sure that certain classes of developers don't get for paid the true value they delivered. A socially conscious user might have paid $X for a New York Times app. However, when diving up their funds, they decide to give all their money to struggling indy developers instead of a big corporation like NYT. That is a sure way to keep good companies out of the market.

I could imagine App.net giving all their users a certain number of App.net bucks to buy apps with, and then allowing for excess purchases with real money. However, this implies a much simpler solution:

Charge less for the base service and let app developers monetize through their own sales that get users to pay what the market price.

One last note, it seems there are a few people who believe paying for the service and apps is double payment. It's not. You pay for your iPhone/data (the platform). You also pay for iPhone apps. The only question is whether the service is charging too much for the infrastructure, when it should be freeing up users' pocket books to pay for apps.

[orianmarx]

@mleveck I think you and I are on the same page

[mleveck]

@orianmarx agreed.

[jschlesser]

@orian i think I agree with everything here, there are so many ideas I need time to really digest and work through scenarios, my brain is full. Does anybody care to summarize approaches? Im getting on an international (12 hr) flight in a few hours and plan to sleep most of the way.

However I do think we all agree that there is a challenging scenario of servicing corporate clients that have a budget but need wide access for their clients and an exceptional user experience and how that meshes with only having 50/yr paid consumer accounts as the only option

If you/we/dalton can solve all these issues

1. who pays
2. how to make it feasible for large 3rd party user bases
3. paying for extreme usage
4. enumerating the benefits in the right context not just to the people paying but also the people using

It will take off like gangbusters.

It may be that the model has to change over time too. Sometimes you might need model A to get to a certain point and then after that the model has to change. I think this is one that only @dalton will be able to decide on because there would be perceived winners and losers and only he really represents the entire network, everybody hates hates change. Note, in no way am i suggesting ads, I mean shifting the funding burden around at various points may make sense to support the right growth at the right time. If we can figure it out so that it never has to change, that would be ideal.

Some things that I try to keep in mind while im mulling this over from the corp perspective.

1. In the early days nytimes etc... will have much larger user bases than app.net
2. over time the app.net userbase wlll be much larger than nytimes, at that point app.net network vs the infrastructure might be more valuable to nytimes than the other way around. However, they may worry about that in terms of 'rules' for corp clients. If I were them id like a guarantee on a good set of operating rules, too bad they arent in this discussion. I guess im trying to proxy for corps.
3. today the nytimes of the world could really use innovative social experiences to solve discrete problems like user engagement and will spend money on it but there are limits and they may want to get their toes wet gradually. They will view it as cost of acquisition and cost of retention for their paying customers which means they probably have a dollar limit on cost per user per year and it might be in the $.50 range. I dont actually know. I havent followed the ad market in a while but 1% of conversion of clicks to paid customers might be a generous proxy to understand the economics of getting a user through ads. Somebody may have to take a risk to prove a new social model and app.net might have to allow them to kick the tires for free so to speak. Note that it wouldnt be free for them, if a corp dedicates people to creating a social experience it is probably a potentially costly risk for them in terms of focus and man months. It will cost to develop.

However, The minute somebody figures it out (makes a much better social experience and starts winning) it will be top priority for every CEO out there. Note, my opinion is that this is the mythical social ad unit, its an experience, not a visual.

1. today there is no incentive for nytimes to consider app.net technology because the network is small and limited by the funding model, any technical work they put into their platform wouldnt effect enough of their userbase. doesnt make economic sense. todays model definitely doesnt make sense or at least only makes the same kind of sense that twitter and facebook make today. That means either the model changes or the network gets big a different way first.
2. today average consumers are right to think that its $50/yr for conversation with nerd, honestly, it mostly is, for me thats great but we need grow out of that and show something that is somehow better than twitter. ads on twitter arent the real problem for most users, its finding the people and the conversation.
3. I think we all want this to be successful and that means Dalton and Co. need to make money, 500K is chump change sadly in the real world (salaries for only a few people where yall are at). Im guessing that 1M wouldn't cover base salary today for a year let alone health and other benefits for the team. Ive been running some numbers on digital napkins and the network will need to be 1M - 10M real people being monetized through corp subsidy and direct payments before it starts to look really good. Nytimes isnt going to be paying $50/user/year, probably a few percent of subscription since its an ongoing cost vs 1 time. .50/yr? The reason that this is important is that corps. will want to know that this is something that is going to stick around and profitability and cashflow is the measure of that.

On Aug 15, 2012, at 12:04 AM, orianmarx wrote:

When I think about this, I always try to start with the premise that App.net is an infrastructure company. As such, when it comes to how they should be pricing things, it should be a reflection on utilization of the infrastructure. It might seem hard to figure out how to determine utilization, but if App.net can't figure that out then they shouldn't be in the infrastructure business (for one thing, I don't think figuring out utilization is that hard and for another, I think the App.net is very capable of doing it).

Now, lets take an example of NYTimes and say it wants to build a service whereby people can sign up to receive a notification when the times publishes a new post. That's all it does. Now lets take another service that is a network of surgeons, and the purpose of the service is to share videos of procedures being performed and share notes on these procedures.

The Times example might be a very large network of users that ends up consuming a relatively small amount of bandwidth. The utility cost for this should be low, and the NYTimes can simply pay for it out of their marketing budget. They should be able to choose to make this service free to users if they want.

The surgeon example might be a very small network that consumes a lot of bandwidth (let's make the assumption that app.net is hosting the video files). Here the utility costs would be high, but it's likely these surgeons would also be willing to pay a high fee for membership in this private network.

In either case, App.net makes its profit as a utility provider. To me the two big questions are a) is the Times essentially prevented from offering a free service that they subsidize due to the fact that there is a base membership fee for all users of App.net currently and b) should App.net make an additional profit from high-value networks like the surgeon one by charging a percentage cut of any services' revenue.

I think App.net will have to move in the direction of as close to zero base membership fee as possible, to get access to the market of services. I think they could take a cut of service revenue, like Apple does, but I think it's likely that they shouldn't. Consider that App.net has to build its userbase concurrently with its market. That was not the case for Apple. They had the userbase by selling the iPhone. I think developers should be rewarded for coming up with ideas that result in services that people perceive are way more valuable than the underlying infrastructure cost to operate with them. That's known as building a high margin business. If you can do that, more power to you.

— Reply to this email directly or view it on GitHub.

[jschlesser]

I think i like the app.net bucks idea that people can spend a lot more than app.net having any other criteria for compensating app developers. However, app.net needs to make money too, they can't give it all away. I think my answer to @orianmarx question of whether the network has value outside of Alpha is yes as long as there are a few good free apps. I also can understand why dalton might want to kill off the Alpha interface, 1) its competitive with the rest of apps that he wants to see built, 2) to make it a good experience would suck up all the dev hours away from the infrastructure and apis. I think that 2 is way more important that 1 since 2 is the actual business and devs need to work on that, a lot. I think that there should be a marketplace to purchase additional apps that are premium as well. A good marketplace could potentially solve trust issues as well. Both discoverability and safety/reputation are issues solved in a marketplace along with the basic transaction.

[markwilcox]

Maybe I'm on a completely different track to lots of people around here but I thought @daltonc had an absolutely brilliant model in the first place with some details to be worked out. Now this issue seems to be suggesting we essentially throw that idea out make App.net into some kind of platform as a service provider like Parse or StackMob but for real-time social feeds?

@orianmarx I've been in strong agreement with a lot of your thinking on App.net but I think you're looking at the revenue side from some unlikely angles and have a terrible analogy with the iPhone there. The iPhone is a piece of hardware, not a service.

Consider instead that App.net is an example of the next generation of telecoms infrastructure. With telephones and a telephone network, you need to both pay for the network and buy a phone (= client application). The majority of the value lies in usage of the network, not the client application. It makes no sense to charge lots of money to buy/rent the phone and give the network usage away for free, with phone manufacturers subsidising the network provider.

With internet access, we got a new layer on top of the phone network (primarily at least) which people were prepared to pay more for. You needed to buy another client (computer and modem) to use it but the majority of the value is still in the network usage. There are plenty of other things you could do a with a computer and modem that used the network but only as a small part of what they were - people paid for those separately. There was a free service (the WWW) that made people want to pay for internet access but it wasn't enough for many people initially, so some early ISPs tried building out additional content and services to make the offer more attractive. Most of them weren't very good at it because they were infrastructure companies, not software application innovators or media companies - it's generally better for companies to focus than try to do everything.

Now one of the next logical steps is global identity management with social connectivity. This service sits on top of the previous services and allows us to connect to others in our networks for almost any purpose we can think of.

Currently App.net provides one consumer service on top of their infrastructure - microblogging. Even if they didn't maintain Alpha and give it away for free, they'd still be providing that service, you just need to buy another client (or pick up one of several free ones) to use it. The strategy for increasing the value of the infrastructure is then to open the platform to 3rd party developers and share revenue with them for increasing the value of the platform.

This strategy works for some service types and not others, however there's nothing to prevent other business models from operating on top of the platform. It does however solve the major problems for people wanting to innovate in social services - building and maintaining highly scalable infrastructure is expensive and reaching your early adopters and getting them to try the service is difficult, you currently have to do both of those things for some significant time with no revenue. With infrastructure a decent sized early adopter user base is already paying for to reuse plus a revenue share deal, the barrier to entry in this space goes down to the point where 1 or 2 developer teams can start innovating.

If people are going to argue against this model I'd like to see some much more plausible use cases...

New York Times publishing to App.net - Why would they - can someone outline a service that would work for them versus many of the routes already open? I'm not saying they'd never want to, just that it doesn't make any sense for anything near the current scale of App.net - if App.net had real scale they wouldn't need to comp users in. Besides - part of the point of users paying for the infrastructure is to avoid it becoming dependent on funding from media companies - I don't see how the NYT being a giant corporate customer is any better than other media companies being advertisers to be honest.

Network of surgeons - small enough to host your own infrastructure cost effectively, even if you do use App.net it would be easily high enough value to have the surgeons have an additional subscription for it. The best argument I can see out of this one is to have App.net incorporate some additional payment processing functions, such that usage of some apps requires a higher subscription level.

@mleveck you said:

Everyone who has proposed that app makers primarily get paid via a cut of user fees, please address the question that dalton originally raised, and led to my initial proposal:

I would strongly argue against anyone that said all apps that use App.net should be free and I think @daltonc would too. The revenue share may only be a small part of some business models - I believe App.net should be business model agnostic (with the major exception of monetizing user data directly there should be something in the ToS that prohibits developers from selling users details or spamming user accounts on the network by sending @messages or direct messages). That said, I think the revenue share aligns economic interests for a lot of app types with the platform.

What fair and efficient metric would you use to divy up the proceeds? Please make sure the payments would accurately reflect the value received by users.

The detail needs careful thinking about but I believe it should be based around posts since they are: a) most likely to be adding value b) easiest to detect apps gaming the system

Time used, posts made, number of users etc. are all highly gameable. They also will not reward high value apps that have a niche market.

There will never be a completely fair system and any metrics used will favour some types of apps over others. Mailing each users apps usage metrics to them at the end of every month and letting them tweak it for their perceived value, or report suspected abuse is probably the best counter-balance to this.

High value apps with a niche market need to charge a separate subscription (possibly collect through App.net if this makes sense) or high upfront cost for the app. This is true for niche apps whether they are on App.net or not. Consider also other app types: 1) Those that only make a small use of App.net - e.g. Instapaper/Read It Later type apps that share article links to the network - the bulk of the value does not come from the network, the revenue share is just a small incentive for developers of such apps to integrate with App.net as an option. 2) Those that trawl App.net to organise content - e.g. Flipboard style apps - these are primarily extracting value from the network, not adding it - they should not get much/any revenue share but charge users up-front for the app. 3) Turn-based games - how many turns are you realistically going to get through in a day? For most people this should be fewer posts than straight conversations with their peers. Could be paid or free up-front with standard proportional revenue share. 4) Real-time games (if possible) - probably doesn't make sense to use App.net infrastructure for any more than lobby functionality but if actually used for exchanging in-play data then I'd guess higher rate limits (and a higher subscription, with revenue share only from premium subscription portion) would be required for this type of app. 5) Enhanced micro-blogging clients - I'm sure there will be free clients (how to revenue share to the open source ones isn't entirely clear - probably best to leave that up to the teams that implement them though - still share to whichever dev account publishes and just ban undifferentiated rebuilds from source), clients that want to charge will need to offer extra features of a better UX. Revenue share for all based on usage seems very fair. 6) Chat apps - Does direct individual and group messaging add less value to the network than public posts? If so, weight these types of post lower in revenue share - likely to be higher volume to make up for it anyway. 7) ... others please add use cases - there are bound to be things invented we can't think of in advance!

For those that think the subscription value needs to come down (excluding issues of regional pricing, which while important should at least be allowed to wait until the App.net business model is proven and the business sustainable and growing), I say it's only just over $4 a month, if we can't collectively innovate services that make it that valuable then the whole thing has failed. We need to see what value adding services are created first and worry about pricing structure later. If sufficient value is added on top then I completely see an argument for adding a lower pricing tier for some basic subset of services (maybe just the original micro-blogging service) to get people in the door. To reach scale in the 10s or 100s of millions quickly would definitely require a free tier but why rush? What's wrong with sustainable organic growth of a paid service? Adding some kind of free tier as a cheap form of marketing when organic growth stalls is a logical move but I'd hope the service would have >1m subscribers by that point and lots of value adds that can be excluded from the free tier.

Can you reach scale of 10s or 100s or millions of users at $4/month? Of course you can. How many people have phone service or broadband in the world? How many people get that for free? This is much cheaper and has the potential to easily be worth that to everyone with a connected computing device. Those who don't see the potential value are mostly stuck in the "ad-free Twitter clone" mindset.

For those that are concerned about big companies not coming and building on App.net at this point, or not getting fairly compensated for doing so - this platform needs innovation to create value for users. The record of most large companies innovating in this space is awful. Much better to set up the incentives to favour startups and small independent developers.

[orianmarx]

@markwilcox great stuff here. It's a lot to digest. This is arguably harder to figure out than the permissions issue because it comes down to a certain degree of speculation and market theory. That said, you're right that @daltonc's proposal is very interesting and I didn't mean to shortchange it. I certainly like what is motivating the thinking behind it, I'm just not sure how well it would work. There are some interesting forces that would be at work: developers would have an incentive to make apps that consume the most user attention as possible in order to capture the most rev share. Concurrently, the growth of the app ecosystem would be inversely proportional in some way to the amount of revenue an app could capture as part of a user subscription fee share. However, that might be counteracted by growth in the overall userbase. It's definitely an interesting model, I'm not opposed to it at all, I just haven't really wrapped my head around it.

I also want to reiterate that I am not pushing for a change to the subscription pricing any time soon. I just want the conversation to consider both the short term and long term issues.

I should point out that I am less interested in how big players like the NY Times can end up using this infrastructure vs my surgeon example. I agree that smaller players are generally more novel, and we should be building an ecosystem to foster that first.

Along those lines, I do think App.net should strongly consider a role as a payment processor to make the process for purchasing / using apps in the ecosystem extremely fluid, whether or not there is also a rev share model. Considering the size and growth projections of the markets that Apple and Google have created for their mobile devices it certainly seems like a significant goal to aim to build a similar one for services running on the web.

[markwilcox]

There are some interesting forces that would be at work: developers would have an incentive to make apps that consume the most user attention as possible in order to capture the most rev share. Concurrently, the growth of the app ecosystem would be inversely proportional in some way to the amount of revenue an app could capture as part of a user subscription fee share. However, that might be counteracted by growth in the overall userbase.

I think you might be looking at edge cases (users running a large number of different App.net apps) here rather than typical cases (users only using a few App.net apps on a regular basis). You'll be much better off optimising market share of App.net users than trying to significantly increase app usage beyond what adds value for the user. At $0.50/month revenue share times 10k users an independent dev can afford to work full time on their app.

I think the payment processing idea is an interesting one, although I'm kind of expecting more native (mostly mobile) apps than pure web apps - and those do already have some simple monetization routes to generate extra revenue - you wouldn't be able to in-app purchase on Apple devices for a premium app.net subscription without Apple taking a 30% cut and you can't charge 30% more than the direct web price. :(

[fwanicka]

@markwilcox I am with your line of thinking 100%. I think @daltonc had the right approach in his initial proposal. That is definitely the model I see having a future, and it's why I paid the $100 developer fee. If the plan gets switched around where users directly buy the apps and then the app developer has to pay for the infrastructure, you are going to quickly be right back in the lose/lose scenario Twitter is in now. If I have to worry about how I'm going to get users to directly pay for my app right off the bat, it is going to take my focus away from creating the best app I can. If the user has already paid, then my focus is solely on creating the best app possible.

I think this new approach could be revolutionary if we can just stick with it, and be patient through the growing pains that will inevitably come. I think with that model you could see some amazing new apps come out of this community.

The revenue-sharing algorithm probably won't ever be perfect, but that's no reason to abandon the idea. It's still a much better solution than the current status quo. I'm willing to risk a bit of unfairness and/or gaming in the system.

[JoshBlake]

Coming back to this thread --

After mulling over different options for rev-share and seeing the types of apps people are making and discussing (plus brainstorming plenty of goofy and some serious ideas on #ControversialADNideas ), here are my latest thoughts:

The payment mechanism and revenue model should be directly based upon how much the user values the application. If we approximate value with the wrong metric (such as number of posts) then developers will be incentivized to elicit weird behaviors from users (such as posting all the time.) The revenue sharing model needs to be flexible for different types of applications that deliver value in different ways.

Let us discuss what best approximates the value the user assigns to an application by considering several different classes of applications:

Social Applications

Social apps are basically Twitter-style microblogging applications. They let users consume and create posts to communicate with other users. The user has many short but intense sessions using these applications, typically almost every day. During a session these applications have a high volume of read API calls, perhaps 300/hour, but do not make API calls during other periods. (Ignoring push notifications for now as API is not fully developed here.)

The user uses the application almost every day and has integrated the application into her lifestyle or social life. The number of posts generated will be based upon the individual user's social nature though and do not reflect the value the user gets from the application.

Each session of directly using these applications has only a moderate value, but there are many sessions and the availability and consistency of the application overtime is important.

For social applications, the time spent in application making high-frequency read API calls best approximates the value of the app to the user. If the user likes the app, she will use it all the time. If not, she will switch.

Monitoring Applications

Consider a utility application that monitors a user's stream for mentions and certain keywords or hashtags, or a application that continuously backs up posts or cross-posts to other services. Also consider games that extend over long periods of time, involve background use of the ADN API while the user not using the game, or are turn-based and take hours or days to complete.

For these applications, the user would only spend a very limited amount of time directly in the application, such as during initial authorization, while taking a game turn, or when changing settings every once in a while. The application would make relatively low frequency number of API calls, perhaps 10/hour, but would do so all the time, 24 / 7.

Each session has a relatively low value but the fact that the application is working in the background is important.

We might think that the number of notifications the utility sends to the user represents the value, but this is hard for ADN to measure directly and the user could be extremely interested in a rare keyword.

For monitoring applications, the period of time (in days) that it is active (making low frequency API calls) best approximates the value of the app to the user.

Single Serving Applications

This class of applications the user may use once for a specific purpose at one point time but otherwise the application is not acting on behalf of the user. Examples might include analytics applications or bulk backup/import/export utilities. Real-time games may also fall into this category if the game only uses ADN services during short, real-time gameplay sessions. Random goofy utilities or single-purpose apps ("What is your App.net birthday?" etc.) are another example. API usage can vary from very high to very low.

The main differences between social applications and single serving applications is that single serving applications are not used as often and involve non-microblogging activities.

Users might only use these types of applications once ever, or perhaps sporadically multiple times. During use the application may make high-frequency use of the API, but only that one time.

Each individual session brings a large amount of value to the user, but the absolute value depends upon the nature of the application.

The Token Pool Revenue Sharing Model

I use the term token to mean one unit of a micro-payment from the user through ADN to the application developer. The user would automatically get a certain number of tokens per month with her subscription, representing a portion of the subscription fees, and have the option to buy more. Unused tokens do not expire and would remain available in subsequent months. Tokens are easier to deal with in a marketplace than many different currencies. The value of tokens will depend upon how much of the user subscription is made available for revenue sharing.

The value of each class of applications is measured in different ways. Below I summarize the value approximation metric and suggest various options the developer could use to get revenue for each class of apps.

• Social applications
  • Value metric: Number of hours during which the application made high-frequency API calls during interactive user sessions
  • ADN sets a subscription price (tokens/month) to enable all free social apps. This price goes into a pool of tokens for all social apps. ADN automatically divides this pool between all social applications based upon the proportion of hours spent in each.
  • Premium version: Developer sets a subscription price (tokens/month) and user agrees.
  • Apple App Store: Lite apps participate in the free edition revenue sharing pool. Paid apps opt out of revenue sharing and get paid through App Store.
• Monitoring applications
  • Value metric: Number of days the application made low-frequency background API calls regardless of interactive user sessions
  • ADN sets a subscription price (tokens/month) to enable all free monitoring apps. This price goes into a pool of tokens for all monitoring apps. ADN automatically divides this pool between all social applications based upon the proportion of hours spent in each.
  • Premium version: Developer sets a subscription price (tokens/month) and user agrees.
• Single Serving applications
  • Value metric: The number of sessions
  • ADN sets a subscription price (tokens/month) to enable all free single serving apps. This price goes into a pool of tokens for all single serving apps. ADN automatically divides this pool between all single serving applications based upon the number of sessions each were used.
  • Developer sets a purchase price (tokens) that grants the user unlimited use.
  • Developer sets a per session price (tokens/session) that the user must pay each time.
  • Developer sets a price for in-app purchases (premium version upgrade, or multiple in app items).
  • Apple App Store: Lite apps participate in the free edition revenue sharing pool. Paid apps opt out of revenue sharing and get paid through App Store.

Note - this may seem a little complicated at the moment with the different classes of applications. Visualize the UI of an app marketplace and the different categories it would have. All the free editions of apps in a category would be available if the user subscribes to the category. It also might make sense to have more or different categories. These ones are just a discussion starting point.

Note 2 - I say free apps and premium apps but this can also just mean the free edition and premium edition of a single app. Example - QuickApp may have some features for free and @dquick-freelance would be reimbursed based upon the popularity of his app, but he can also have a premium version available for an additional fee per month.

The prices for the free category would be set such that a user can enable all three (or more, if there are more) categories within the available tokens granted with the subscription per month. To get premium versions, the user can buy more tokens. Alternately, if she really likes just one social app she could disable the free social app subscription and subscribe to the premium version of the one social app she really likes.

Price anchoring

The other really interesting this about this model is that from the start, there is a concrete price for the app categories. That price anchors the value of applications in the user's mind and I believe will prevent a race to the bottom that was seen in other app stores. For example, if the social application category cost T4000/month for all free editions, then a good price range for premium editions might be between T1500/month and T3000/month. The higher end basically meaning the app developer believes her app is worth almost as much as the entire free marketplace. If that high-end app can serve all of the needs of the user for that category, then it might be true!

The comparison of the two prices is psychologically important too. The lower price for the one or two premium app looks like a better deal than the whole category of free apps that she doesn't really use most of.

I don't know how much T1500 will be worth as it depends upon how much of user fees are available to the apps, but suppose 100 tokens (T100) = 1 US cent. T1500 would be $0.15 USD. That looks bad compared to $0.99 app store prices, but remember that is per month. Over a year the value is $1.80/user, and you keep getting paid more over time, as long as you keep your app working and relevant.

Empowerment and incentives

I'm sure there are some wrinkles that need to be ironed out and some details to be filled it (not sure about App Store policies...) but I think this model is interesting. It would empower users to support developers directly through the free category subscriptions or premium versions, and would let them unsubscribe from any categories they don't use so they aren't paying for something they don't use. I think this also puts incentives in all the right places. For app developers, it's about delivering value to the user and keeping the user interested in using the application over time, not maxing out the API usage.

[jdscolam]

This is interesting, and I want to chew on it more before giving it a +1, but I have two questions. First, how would app enablers (like Rapptor) get paid, or should they even get paid? Secondly, why a token system instead of just saying "You have $x.xx to spend on apps within App.net"? I hate MSFT Points for specifically that reason, it doesn't make any real world sense, but if people could say get $2.50 a month to spend on apps, and apps range are in the $.01 - $.30 price range (more depending), then that would possibly make more sense to the average user. Thoughts?

[markwilcox]

A whole bag full of interesting concepts here. I'll start with some questions...

Hours of high frequency API use is surely the most open metric for gaming isn't it? On iOS you'd most likely get rejected for inappropriate background activity but for Android or a desktop or web app running all day in a tab you could simply make peroidic bursts of API calls whether the app was in interactive use or not. How do you avoid that? Similarly you can make low frequency background API calls on most platforms whether the user has requested them or not - you'll probably end up monitoring how long the app happens to have been left running rather than how much it was actually used.

How do you handle apps that cross multiple categories?

Why should paid apps on the app store opt out of revenue sharing? At the current size of user base I'd expect apps would need both to be economically viable. The revenue share is likely larger for most than users will typically pay up front and a subscription model will be tricky outside of high value niches when the user is already paying an app.net subscription.

Having fixed amounts per category suggests that if a user only uses one category of app then ADN keeps more of the revenue. If the full $50/year of value is satisfied by that one category, shouldn't all of the available revenue share be divided between apps they use from that one category?

Should the revenue share model attempt to maximise value to the user from each individual application, or rather the value added to the platform? Are those the same thing? I believe not. For example, private vs public posts and reading vs posting.

On initial impressions I still prefer something related to posting, or maybe some sort of combined API usage metric with some gaming detection algorithms. Additional posts in meaningful numbers either have to be automated (which should be banned as abuse) or ask the user's permission (which would get really annoying). As I see it, the simplest way to avoid over favouring naturally heavy use apps is to compare the numbers on a logarithmic scale for relative revenue share - that also produces rapidly diminishing returns on any attempt to artificially increase usage frequency.

I think it might be a mistake to attempt to make the revenue share fit most/all types of app. People who are prepared to pay for access to a social network are probably going to be happy to pay for quality software that helps them get more value out of it too.

[JoshBlake]

jdscolam wrote: First, how would app enablers (like Rapptor) get paid, or should they even get paid?

So basically, middleware and libraries? If one develops a library or middleware or some other service and your customer is app developers, rather than ADN users. The most basic solution would be that that transaction would be out of scope of the ADN marketplace and would be up to the developer to sell their software to other developers in the traditional way. (You don't see developer libraries sold via the Apple App Store, right?)

If there was a huge demand for this, I suppose ADN could open up a dev2dev marketplace or somehow allow developers (or any user?) to transfer money or microcredits to other developers.

jdscolam wrote: Secondly, why a token system instead of just saying "You have $x.xx to spend on apps within App.net"? I hate MSFT Points for specifically that reason, it doesn't make any real world sense, but if people could say get $2.50 a month to spend on apps, and apps range are in the $.01 - $.30 price range (more depending), then that would possibly make more sense to the average user.

One reason is that if the ADN balance use local currency, then it gives the impression that the money is fungible or transferred outside of the ADN marketplace, or even worse give the impression that a user who does not use the whole balance should be entitled to pay a lower subscription rate or be refunded the balance.

As for the exchange rate to tokens, I could go either way, honestly. I just provided an example, but I'll share my thoughts. I think that there is psychological value to having prices be large numbers. For example, if an app is priced at $0.15/month in real currency, presenting the price with a small number like T15 makes it seem like a cheap and low quality, while presenting it as T1500 makes the app seem to have more value and higher quality and may make people purchase more. Sure, it obscures the real-world price, but if that gets people to purchase more then it is good for the developers.

It's not about misleading the users/customers into overspending. (We're talking about spending/allocating $1-2 on apps per month total after all, included in the subscription price.) It's about getting over the psychological barriers to spending in the first place. Consumers are irrational about purchase decisions so anything we can do to smooth it out will make it a better market for developers, which will make it better market for users.

That's why I proposed assigning a value to free apps and giving users a bunch of tokens for free. It establishes that all apps have value and that users must compensate developers for their apps, and makes it super easy to spend that first token.

[JoshBlake]

@markwilcox wrote: Hours of high frequency API use is surely the most open metric for gaming isn't it? [...] you'll probably end up monitoring how long the app happens to have been left running rather than how much it was actually used.

Here's the thing though - you cannot determine the difference between a user that just leaves the app open all day on a second monitor to watch traffic while they work or whatever and a user that leaves it running on their computer and goes away overnight. Either way, that is not "gaming" the system, that is how the user chooses to use the application.

In the case of an application that tricks the user by continuing to run and make API calls in the background when the user tried to close it, well, it would be impossible to detect that through API usage; however, technical users might notice and terminate or report the app. Non-technical may not notice. Again, here, maybe this is a feature of the application to provide background notices or something. It's impossible to tell.

At the very least, measuring the number of hours the app is active incentivizes running for a long time rather than maxing out the API calls. (I mean, if we were counting the number of posts or number of stream queries, the app would try to overload the infrastructure instead of just make a minimum number of calls per hour.)

The other thing about the pool system is that even if the absolute number of hours is skewed, it only depends upon the proportion. If the hour counts skew high because people tend to leave apps running, that's fine because that would affect all apps and it would even out.

@markwilcox wrote: How do you handle apps that cross multiple categories?

Give an example where the different categories would need to be in a single app, please. Most likely the developer would be better off creating independent applications, even if the branding was consistent.

@markwilcox wrote: Why should paid apps on the app store opt out of revenue sharing?

I was intending it to be the same for premium apps outside of the app store. This could go either way, but it should be consistent. Either the pool of money is split between all applications or it is split between only the uses of the free editions. The premium payments should more than make up for the loss of the free tier payments.

I mentioned on https://alpha.app.net/joshblake/post/185757 that there is a balance between the pricing of the free tiers and the recommended price of premium apps such that a user could buy 1-2 premium apps for the same price as the free tier subscription.

If an application has both a free edition and a premium edition, the developer would receive payment for the proportion of use of the free edition as well as the premium subscriptions. I believe the hours spent by users in the premium subscription version should not count towards the free pool, though. This ensures that there's always some incentive for providing free applications and this incentive is not overly diluted by premium applications.

@markwilcox wrote: If the full $50/year of value is satisfied by that one category, shouldn't all of the available revenue share be divided between apps they use from that one category?

Good point. This would imply that unused tokens would expire and be added to the pool. I don't like the idea of additional tokens that the user purchased expire though. It may be complicated to have some tokens that expire and some that don't.

Maybe it could simply say "With your account, you get X tokens to use per month for purchases or subscriptions. Any unused tokens at the end of the month will be split between all of the free applications that you used." That would encourage users to use their whole balance purchase apps and leave very little left for the free pool. Should there be a minimum portion of the $ subscription fee automatically allocated to free apps? I don't know -- needs more discussion.

@markwilcox wrote: Should the revenue share model attempt to maximise value to the user from each individual application, or rather the value added to the platform?

I say they're the same thing, but if not, maximize value to the user, not the platform. Maximizing value added to the platform is the whole reason we got things like viral gamification (Farmville and the like, Zynga etc) because those platforms value eyeballs since they're advertising driven. ADN though is user driven, so as long as apps provide value to the user by use of ADN and integration with others, the user is more likely to stay subscribed as well as recommend friends to join.

@markwilcox wrote: I still prefer something related to posting, or maybe some sort of combined API usage metric with some gaming detection algorithms. Additional posts in meaningful numbers either have to be automated (which should be banned as abuse) or ask the user's permission (which would get really annoying).

No -- any reward related to number of posts is a bad idea. If you reward lots of posts you will get apps that encourage users to post too much, which leads to noisy posts and low signal-to-noise ratios. That will destroy the platform. Additionally, there are all kinds of ways that the platform can be used that may involve automated posts or other creative applications and we do not want to artificially restrain those with rigid and hard to get right rules about "your app gets paid per post, but don't post too much, and you have to bug the user if they want to post more than this much".

Automated gaming detection is a similarly losing proposition. The reward metric should be apparent to the end-user, and that user can make corrections or report abuse if necessary. That's what I tried to do in the app categories. It's not perfect but it's pretty good. It would be helpful to send an app usage report to the users per month, and they could see very clearly whether an app credited for use when it shouldn't be.

@markwilcox wrote: I think it might be a mistake to attempt to make the revenue share fit most/all types of app.

I think it would be a mistake to not revenue share all types of apps, otherwise the types of free applications available would be biased. If you only revenue shared for social microblogging apps then developers will favor building that type of app too much over other types. (The "free" revenue shared apps can serve as trials for premium versions.)

@markwilcox wrote: People who are prepared to pay for access to a social network are probably going to be happy to pay for quality software that helps them get more value out of it too.

The model I suggest allows that. A developer is free to set a high price or only have a premium version, all paid through the app store, but revenue share should not be limited to certain types of apps.

[markwilcox]

@JoshBlake wrote: The other thing about the pool system is that even if the absolute number of hours is skewed, it only depends upon the proportion. If the hour counts skew high because people tend to leave apps running, that's fine because that would affect all apps and it would even out.

This only applies to apps that work in a similar way running on the same platform. If I have a web client that uses streaming to fetch updates continuously in an inactive tab I use occasionally it's going to have much greater API usage than my mobile device client whether I actually read 10x as much from the mobile device.

Playing devil's advocate a little here, shouldn't a great social network app actually be more like Google Search than Facebook for some people - the more it filters out noise and gives you only the most interesting links and conversations the less time you spend browsing through dross and idle chatter. Having a usage time metric actually stacks the incentives against developers improving their clients in this way. Such an app may even be something of a hybrid between a social app and a monitoring app... which brings me onto:

@JoshBlake wrote: Give an example where the different categories would need to be in a single app, please. Most likely the developer would be better off creating independent applications, even if the branding was consistent.

The way the incentives are split amongst categories it's clearly better for developers to create independent apps in different categories but is that always better for the user? I could imagine wanting something that tells me my followers ADN birthdays, prompts me to congratulate them on the happy event and then continue the conversation within my "social app". Isn't that better as a feature of the social app than a completely separate app? Similarly, at least for a desktop app, I'd want monitoring and alerts as part of my social app. How about a massively multiplayer turn-based game with built-in chat features (think a giant version of Civilisation)?

@JoshBlake I was intending it to be the same for premium apps outside of the app store. This could go either way, but it should be consistent. Either the pool of money is split between all applications or it is split between only the uses of the free editions. The premium payments should more than make up for the loss of the free tier payments.

Maybe a distinction is required between one-off payments and premium subscriptions? At the prevailing level of app purchase prices on Apple's store I can't see them making up for loss of revenue share. Incentive to produce a free iOS app when there's already a revenue share is simply that free apps typically get at least an order of magnitude more downloads. You'd have to be really confident your app is of superior quality to free ones to charge.

@JoshBlake wrote: ADN though is user driven, so as long as apps provide value to the user by use of ADN and integration with others, the user is more likely to stay subscribed as well as recommend friends to join.

I should rephrase my original - instead of maximising value for user vs platform I really meant individual user vs all users of the platform. e.g. a direct message may be very valuable to the individual user and recipient but a public message is potentially valuable to thousands of other users. I don't really have any answers here, just think it's a question worth considering when designing the revenue sharing system.

@JoshBlake wrote: If you reward lots of posts you will get apps that encourage users to post too much, which leads to noisy posts and low signal-to-noise ratios.

Can you think of many ways to encourage people to post more human generated content that wouldn't be so annoying as to have you switch apps? Maybe there should be special identification, rules and revenue splits for machine generated and machine readable content? Frankly, rather than worrying about how we filter 4sq check-in posts I'd rather we just outright banned them! :)

Perhaps in line with the concept of allowing users to verify their app usage levels in a monthly report, what's really needed is human oversight. Users are very weakly incentivised to catch abusive/cheating apps but developers are fairly strongly given they're sharing the revenue. What about peer reviews for apps, with some tools to monitor API usage? That could work regardless of the actual usage metrics.

@JoshBlake wrote: I think it would be a mistake to not revenue share all types of apps, otherwise the types of free applications available would be biased.

What's wrong with having a bias in terms of what types of application are available for "free" (actually paid for as part of the subscription)? As I see it, apps that are significantly subsidised by revenue share from the service should be those that involve relatively heavy usage of the service - i.e. the user's value from the app comes from actually using the service. Apps that deliver their value in some more indirect way should charge for the value they create directly. That's not to say ADN shouldn't facilitate that payment - I'm in favour of them providing an integrated payment solution. Analysis of data from the service is a great example - something fairly one-shot that reads a load of data and does some clever analysis for you to provide new insights should charge for that service. The value is added by the analysis - I think my issue is that I philosophically disagree with setting aside some pool of the service revenue disproportionate to the amount the service was actually used. Not that such an app shouldn't get any revenue share, just that it should be proportional to usage. If the analysis is really useful then surely the user will repeat the process reasonably often? If it's not the sort of thing that would be repeated frequently then it's either a low value service (e.g. throw-away laugh) or should find it pretty easy to charge separately.

How does something like Flipboard fit into your scheme? Or, say, Instagram sharing photo links, or Instapaper sharing article links?

Please don't get me wrong, I think you've got some interesting ideas on a tough problem here. I'm trying to pick holes in them because it smells overly complex to me - adding complexity to any system of this type usually opens up more avenues for abuse and holes that legitimate cases fall down rather than fixing problems. Simple systems will always have some undesirable biases but they're much easier to administer and police and everyone knows where they stand.

If you want to create a more balanced distribution of the revenue share than even logarithmic API use comparisons provide I'd think about really simple caps - e.g. if a user has N apps in use during a month (N > 1), any single app is capped at (1 + N/2)/(N+1) of the total revenue share - I made up a formula for brevity - you could create a table and tweak it if you wanted.