Proof of evolution/activity

[tsukiaka]

First of all, maybe some part of what I am talking about is already implemented. I don't have enough information yet so I am posting this as a "draft" and I will elaborate more later.

PS: Sorry for the writing mistakes, I am not very good with English.

What is the problem you are seeing? Please describe.

Some apps with good payouts are not evolving at all. I am trying Blockstack apps since few months and unfortunately I don't see any evolution or activity for some of these dApps. No new features, no bug fixing, no UI/UX evolution, no attempt to market the app. By browsing on Github of some projects (when the repo is available), I can easily find apps with high payouts but no commits since months, no social media / community presence, etc. These are "zombies", not really dead but not showing any sign of life.

How is this problem misaligned with goals of app mining?

Now the question is: how can we improve app mining to avoid zombie projects? Developing an interesting app should only the first step. Apps should not be rewarded every month only based on their "current state", but also based on their past and future evolution. In my opinion, "zombies" apps have a low potential.

For me a zombie is a project without activity and no plan for the future. Activity can have different forms:

• Participating to an event
• Posting tweets
• Fixing bugs
• Adding new features
• Doing partnerships
• etc.

What is the explicit recommendation you’re looking to propose?

I was thinking maybe we can ask app developers/maintainers to provide a small report every month by responding to few questions. For example:

• What have been done to improve the app?
• What improvement are planned in the future?
• What have been done to attract new users?
• How do you plan to attract new users?
• Do you have a strategy to monetize your app?
• ...

This will allow app reviewers to follow the progress of an app and to have information on the future updates. We will be able to have a kind of timeline/roadmap and to see how each project is evolving and how they plan to evolve in the future. Plus by testing the apps every months, reviewers can also easily see what's new, what have been done/improved, etc.

App mining should be limited in number of payout for each app. For example, an app can't receive more than 12 payouts (it's only an example). Apps should not be automatically reintegrated in the app mining every month. Each month, app developers can decide to reapply (or not) for the next month.

• If they believe that they did well the last month and they plan to be very active the next month, then they can apply and they will have a high chance to get a good ranking and a high payout.

• If for any reason they know that they will not be active, nothing evolved, want to give up the project, etc. then they won't apply again.

This system will allow new fresh apps to get more important payouts while old apps will have to find a business model ASAP to generate incomes. This will also encourage projects to be more active and not become zombies.

[friedger]

Let's push that forward for the next miner call.

While app.co is updated, we can use app-center.openintents.org on a voluntary basis for reporting progress. App ownership is a prerequisite here.

There are already two related issues :
#138

#86

[stackatron]

I think this will be solved by default once we can measure user retention. Not opposed to the overall idea, but also not sure it is based on solid first principles:

Some apps with good payouts are not evolving at all

I know this seems unfair but what problem does this create? I'm sure apps in the Apple or Play store also see zero improvements and yet continue to collect revenue?

Apps will break eventually from Blockstack.js updates. Should these apps be invalid for months, then renewed when they update?

If there are bugs, shouldn't those be reflected in TryMyUI?

If an App Miner wants to build/release an app, then put all energy into another app, I'm not sure this automatically a bad idea?

[tsukiaka]

@jeffdomke, yes I understand your points.

• "Apple or Play store also see zero improvements and yet continue to collect revenue":
  Yes, but the difference is that they generate revenue by themself. I mean they are not paid directly by Apple or Google. Apple and Google stores are very competitive, if an app is not good enough, or if a competitor do better, then revenues will decrease as the app will loose users or have a bad retention. It's kind of "natural selection", they have to survive and evolve to be able to generate revenues for a long time period. And to be honest, I have never seen any successful app without, at least, updates to fix bugs.
  In our case, this apps are paid directly by the app mining program and the competition is still very low. So there is no need for them to offer anything new. I think incentive strategy is good but it's not enough, it should come with more restrictions/rules.

• "Apps will break eventually from Blockstack.js updates. Should these apps be invalid for months, then renewed when they update?": I think they should be and they should be responsible to update ASAP. I mean when a function/lib is depreciated on IOS, Apple won't wait for me, I have to update my app.

• "If there are bugs, shouldn't those be reflected in TryMyUI?":
  Actually from what I saw in my research on Blockstack dApps, apps with an open source repo have enough feedbacks and open issues, but still no new updates to fix these bugs (sometimes small bugs issues open since 2-4 months ago and with no responses). Also I don't know how deep TryMyUI is going on testing.

• "If an App Miner wants to build/release an app, then put all energy into another app, I'm not sure this automatically a bad idea?":
  I think devs should be free to develop what they want. If they want to work on something else then it's fine.

[dantrevino]

@jeffdomke I believe what app mining has created here is a system where people throw ideas out, get a payout, and then move on. Thats not inherently bad. If your only goal is to point to a number of apps, then yeah, great system. But if the goal is to create a quality ecosystem, shouldn't we want apps that are maintained?

[stackatron]

I agree. Which is my my attention is focused on solving user growth and retention measured by an App Reviewer vs. finding ways to monitor/penalize development behavior. I think my position is that user growth and retention are the final goal, and through that a quality ecosystem. Not bug fixes or commits. Obviously one influences but I hope you take my larger point.

@GinaAbrams is planning to publish a more comprehensive plan on the future of reviewers. Think we should discuss more within that context.

[dantrevino]

Noted. Thank you for that clarification. +1

[stackatron]

Discussed with a few folks, sounds like a good next step is to get more thoughtful on NIL testing and criteria. Proposing that we close this and keep that discussion going on #143

[zrixes]

Just wondering if the following would help address part of the issue mentioned above.

Instead of making a lump sum payout to the best dapp of the month, we can split the payout to 3 tranches. 1st tranche - 50% payout of total payout upon determining the best dapp of the month, and 2nd tranche(25% of total payout) 2wks after 1st payout and developers are actively fixing bugs and engaging with early adopters. 3rd tranche(remaining 25% payout) 4wks a fter 1st payout and developers are still actively engaging early adopters and bug fixes pushed out.

The idea is to make the payout across a period of time, measured by some easily quantifiable and general metrics that are essential for quality dapps. This would incentivize developers to continue working on the product and allow blockstack to better manage cash burn as money is distributed at a slower pace. win-win for both sides.

[stackatron]

Trying to design a reviewer that could address this need: #174