stacks-archive / app-mining

For App Mining landing page development and App Mining operations.
https://app.co/mining
MIT License
49 stars 16 forks source link

Proof of evolution/activity #169

Closed tsukiaka closed 4 years ago

tsukiaka commented 4 years ago

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:

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:

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.

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 commented 4 years ago

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 : https://github.com/blockstack/app-mining/issues/138

https://github.com/blockstack/app-mining/issues/86

stackatron commented 4 years ago

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 commented 4 years ago

@jeffdomke, yes I understand your points.

dantrevino commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Noted. Thank you for that clarification. +1

stackatron commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Trying to design a reviewer that could address this need: https://github.com/blockstack/app-mining/issues/174