Last weekend I sat together with @map and we noticed the following behavior on app.net: When you send someone a private message that has his privacy settings set in a way, that the person can’t receive a message from you, then well, nothing happens. For you it look likes that they received the message, but they won’t get it.

Except one of two things is happening:

• they send you a private message
• they change their setting to something that they can receive a private message from you and you send her a private message

In both cases they will see all private messages sent previously.

To understand that behavior I have to get a bit technical here and since I am not a developer, I hope that I do not mess up :)

Sending someone a private message creates something called a channel. Depending on the private message-settings of the user, you have the ability to subscribe her to this channel or not. If not, the channel will be created, it will look like you both are a member of that channel but in fact only you are (at least in my tests it seemed that way).

Now my question: Why doesn’t the sender get an error message? After all for the sender it will look like you are ignoring her and not as if you cannot get the message. Which can lead to real life social problems (like people thinking you are a prick).

From what I gathered my understanding what the reasoning on app.nets side is that:

• the receiver could have a setting in place that he intentionally ignores you (like a mute)
• clients could implement it, if they wanted

Do you see already the contradiction in that argumentation?

If not, I will explain it to you. You can check if you can subscribe a user to a channel (there’s a flag for it in the user details when you ask for it called “you_can_subscribe”). If the user has privacy settings in place that she can’t receive messages from you, the flag is set to false.

Now what happens, if a user has muted you but has her private messages set up in a way that she can receive private messages from all? Well, “you_can_subscribe” is set to true, but she won’t see your message.

Well, if a client implements a check wether you can send someone a private message or not, the client would as I understand it check for “you_can_subscribe”. When the person has appropriate privacy settings in place, the flag is set to false, if not it is to true, wether or not she is muting you. Thus people who intent to ignore you will still seem to ignore you.

And now again my question: Why the hell doesn’t get the sender an error message? As in an error from the API? Clients usually have already something implemented to show you error messages - they are not always look nice, but they can do it. But the check for it, is an extra step that has to be implemented. And since they can only implement it in a way an error message from the API could show it, the API could directly throw the error. That way, when it gets implemented even clients that are not getting updated often (I look at you Netbot) could have this feature immediately. Or am I seeing something wrong here? If yes, please correct me in the comments.

If you see it similar to me, that there should be an error message thrown by the API, please write the app.net-staff.

Best chances are probably to write support@app.net and writing directly to @dalton, @berg and @mthurman. The more who write them, that this is a problem, the better the chances that it gets corrected in the API. After all, it is a network where we are the customers and which thrives not only from good clients and happy developers but also from happy users. And I know already some unhappy users because of this.

Yesterday the guys from Riposte released an update of one of their clients, which is fairly popular. Originally it cost $5, then went free and now they added an in-app-purchase for $5 for some additional “pro”-features.

Of course there were immediately some people that felt ripped off, it had a bit of bad taste for me but not for long and then there was also at several places a discussion about the Developer Incentive Program (henceforth DIP), too.

What is the DIP?

If you know what the DIP is, just jump to the paragraph after the next one. So, what is the DIP? Each month users of app.net get an e-mail from app.net to rate the usefulness of clients they used. If you are a subscriber to app.net your vote counts, if you are a user of a free tier, your vote is “just” important for the statistics. It was promised if I remember correctly that the developers will get at one point the feedback from those mails, thus the “free vote” is important here as well.

Developers can apply for their clients for the DIP and if they get accepted, any user who uses the client will get asked in the feedback-mail to rate that client. Then there is an unknown algorithm that weights the votes by the kind of API-calls the client does (specialized client or a client that does all you can think of) as far as I understood it and then developers will get a share of $30.000 (subject to change - with more users this amount will rise). That’s the DIP.

Some history

Now some recent history. Netbot got released by Tapbots and cost a certain amount of money. Everybody expected that they will be pretty succesful, since they are famous from their Twitter-client and many people still see app.net as a paid form of Twitter (which it isn’t). After some weeks they made Netbot free because sales dropped with the reasoning that they want to get more users to the platform, their client will help to do that and with more people using Netbot, they will get a bigger share of the DIP.

There was a big uproar in the community, and I have to say that I was also one of the people who didn’t like the move. After all a very popular client that will get guaranteed downloads from Twitter-switchers and it will be hard to get people use other clients. In addition Netbot makes app.net look like Twitter to them because they get the exact same experience as with Tweetbot. Therefore it might even hurt app.net.

But Netbot wasn’t the first client to be free. The first client on iOS for app.net was Rhino and that was free from the beginning. Another popular app.net-client called Rivr was free, too. It just offered an in-app purchase for push notifications. All the other clients cost money. But since they won’t attract users as easy as Netbot, it is in my opinion a bit of a different story.

After Netbot got free, Riposte, a very polished client that cost $5 got free. The reasoning was more or less: Netbot got free, our sales dropped, so we correlate that to Netbots gone free and to have a chance at all, we go free, too and hope for the DIP. Thank you all who paid, with that our push-servers are financed for quite some time.

Other clients went free as well, but none with the fanfare as Riposte (and hAppy went free and when some users complained that Felix still cost money while so many clients are free, Dominik Hauser, the Dev of hAppy began charging again for hAppy).

Double-Dipping?

Now Riposte released an update and added an IAP for $5 with some neat “Pro”-features. Naturally there were users who felt double-dipped. Others got Riposte for free and pay now $5 to get the features and they have paid after all $10 when they wanted the Pro-features. I had a bit of a bad taste in my mouth but then thought, well the first time I paid for it, I put some money in the pool for as all having push notifications with Riposte. That’s ok with me. Would be nicer if I got the features for free, but hey, it is their decision. And for people who use Riposte as their main client, then they probably use it on a daily basis. And $10 for a software I use daily is not a lot of money. Especially I have the feeling that people only feel that they get double-dipped because Riposte went in the meantime free and others get the whole package for $5 instead of $10 and so feel treated unfairly. But to be honest, how should the developers handle it? They can get their client out for free and if you really like the client, you can upgrade it. I don’t see how they could check when you bought the app, a separate app is not good, either etc. So, don’t feel double-dipped. If you don’t like it, don’t pay for it. If you think other clients are more feature-rich than use those. So why oh why all the time whining?

I think Riposte Pro looks interesting but it’s a bit hard to justify for me the payment since I have so many clients. But the features look very interesting. And it is the first time for a long time that a client could convince me to move from Felix for my day to day usage to it.

DIP - Pain or Gain?

But what about the DIP? In the Patter-room German there was a short discussion again about the DIP if it is an incentive for devs or if it hurts the platform, since it prevents further development. And now I have to come back to Netbot and Riposte going free.

One of my two majors in university is political economics (which I already finished) and there we talk a lot about incentives. The aim of an incentive is to steer people in a certain direction. The aim of the DIP, as I understand it is to steer the developers to continue to enhance their clients and try some other concepts as well. Since when they do good, they not only get a lot of usage of their apps, but also get continually money from the DIP. Since app.net determines the weighing regarding the API-usage, they could even steer developers into certain directions to develop certain clients. For example if they would be transparent in how their algorithm works, and they say now: Clients that only do a few specialized API-calls get weighted triple in comparison to a client that tries to do everything, it incentivices developers to develop specialized clients instead of a swiss army knife. If they would say API-calls for showing the stream of a users without any filters will loose some weightening, it could steer developers into a direction to not develop further clients that expose the microblogging-part of app.net.

But all that will only work, when app.net is transparent regarding their weighing. Otherwise it is just a bonus to development.

The next question is, wether only non-free clients should be included in the DIP. After all it seems that there are clients that can make some kind of a living just from the DIP. And since they are free, they have a bigger chance of broadening their usage and therefore broadening their share from the DIP. In addition they drive the prices down for other developers, since people will expect that clients are free or at least very very cheap (as in not more than 1 or 2 bucks).

I can understand that reasoning but at the same time those clients loose out on sales. When the free tier got released, I really wondered how much money Netbot could have made, if it wouldn’t have been free. Loads of the newcomers went probably straight to Netbot and would have gone there also if it wouldn’t have been free.

In addition it makes things really complicated. What do you do with clients that do some kind of promotion and go free for a day? Should they be removed from the DIP forever? What about clients that cost only $1 instead of 5? It would make the whole concept so complicated that no one could really handle it. So, I think free clients should be in the DIP as well.

Does it hinder clients from getting developed further? Well, there is the case of Netbot, which is a clone of Tweetbot with some small updates and which doesn’t get a love for some time now. It is still pretty popular. So, they might still get money from the DIP. But as long as income is not high enough to justify further development, it is a move I can fully understand from Tapbots to just let it sit there. Why should they put in more development time, if it is just too expensive because income is so low? I don’t say that I like it, but I can understand them. And the longer Netbot doesn’t get updated, the more users will search for alternatives. And over time the DIP-share will decrease. And at some point Tapbots will make their mind up wether there is enough money in the app.net-client-market or not. And it doesn’t cost them any money to have Netbot sitting there in the AppStore.

So usually you get money from your sales and with app.net you get a bonus because of the DIP. The better your client, the more money you get. And since the number of users for app.net is relatively small, it is not a lot of money you can get from sales. We have now ca. 90k users. Let’s say all use iOS and buy a client for $5 from the AppStore. Then it is $450.000 what you would make. That is actually not a lot, when I think about what it means to work full-time on a client. So the DIP adds the extra that could mean that your succesful client in the small market gets further developed, even so sales will be low because of the market size. If a government would do it, we would call it a subsidy. The effect of subsidies is that they distort the market. In terms of app.net this means that it distort the market in a way that clients get developed or continued to be developed, that wouldn’t have been developed in the first place or would stopped being developed because feeding your family is actually more important and so you would rather work on another project.

In addition it works as a signal (yep, signalling-theory is nice, too ;)) for developers that app.net cares about developers. They do not pay them to develop for their platform. That would send another signal. Microsoft is doing that as far as I know for Windows Phone. That signal would say, hey, we need desperately clients, so we pay you for doing it.

No, they give you a bonus, an incentive to develop for the platform. You still have to make something on your own that is succesful to get your share of the pie. It shows that they care enough to give out some of the subscription money to the developers. And this is probably far more cost-effective than paying directly.

Henceforth I guess in terms of signalling it is a very good thing that it exists. So it might also be called the Developers Signalling Program. But if they would make the weighing of the algorithm public, it could also be a powerful mechanism to steer development of certain types of clients. But my gut feeling tells me that people wouldn’t like it, when app.net started to directly influence which type of clients people develop with the DIP. So they are probably better off in not doing it in a transparent way.