This task discusses an upcoming support product we plan to offer. This discussion is intended for users who may be interested in formal support, or who currently use or are interested in prioritization.
Summary
- We are no longer accepting Paid Prioritization requests.
- We will offer a support product soon which fills some of the role that prioritization filled, plus some new roles which have arisen in the last couple of years.
- Support will be month-to-month and give you a set number of incident points. These points can be used to ask us support questions, or can be allocated to indirectly prioritizing features you are interested in.
History
Historically, we offered limited control over our roadmap through Paid Prioritization, where you could pay us $150/hr to prioritize features on our roadmap and we would accept all of the delivery risk. The main goal of this program was to help us assess the real priorities and value of different feature requests. Many users self-report every request as very important, and if we took them at face value we would end up mostly implementing requests from users with the greatest amount of free time to ask us for features. Having lots of free time tends to be negatively correlated with your time being valuable, and thus negatively correlated with your request being important, so "the squeaky wheel gets the grease" did not seem like a good metric for assessing value and priority.
Asking users to at least claim that they'd be willing to pay $150/hr for features helped identify which requests represented real value (for example, because they would save time for employees) and which requests were not as valuable in concrete terms (even if the reporter might care strongly about the feature).
This program also attempted to reduce the amount of meta-work we were doing to sign contracts, deal with payments departments, etc. It was much cheaper for us to accept all the delivery risk than wade through organizational logistics for each request. This worked fairly well; we only ever had one request go AWOL.
Overall, I'd guess this program was extremely successful about half the time, and no worse the other half (usually, it just became a framework for going through a more standard process).
However, the value of this program as a prioritization signal has dropped over time. As the project has grown and we've launched SAAS, we now have a far clearer picture of which features are legitimately important. The needs of organizations we interact with have also shifted and we have more customers who we have long-term relationships with which are largely characterized by infrequent requests for more traditional support (e.g., "this weird thing happened on our install, how can we troubleshoot it?").
Finally, things that installs want prioritized are increasingly bimodal: either completely trivial or gigantic. This has always been true to some degree, but our ability to perform accurate technical planning has increased over time and the horizon for that planning has extended: we now have a much clearer picture of where most parts of the product and codebase should be and how they will integrate and relate years into the future, so a request to improve something is often entangled with all adjacent plans to make related improvements, and plans beyond that, and beyond that, and so on far into the future. This is a good thing on the balance: better technical planning results in a better product and greater efficiency in improving it. But it negatively impacts our ability to deliver some features quickly.
Two recent examples are Inline Comments and T12664, where there was interest in very narrow features (the ability to hide all inline comments; support for parsing metadata from hg log --patch) but detailed planning supports discovery of large clusters of related features which expand scope. Recently, many prioritization requests end like this: a huge quote for a scope way outside the actual request, which has good technical justifications but isn't very appealing to the requestor.
In summary:
- Prioritization is no longer very important as an actual priority signal.
- Prioritization does not map well to evolving relationships with installs, which are often structured more like traditional support relationships.
- Prioritization is often no longer a reasonable fit for our modern technical roadmap.
Since prioritization is no longer a great fit for either us or for requestors, we will no longer accept prioritization requests. We intend to replace this product with a support product, described below.
Support
Instead, we plan to offer a support product in the near future, driven by Nuance. T12134 has some information, but that task mostly discusses evolving free support.
We expect the support product to work roughly like this, with the caveat that all of this is still in flux:
- You pay a monthly fee for support, say $100,000,000,000,000 per month. There may be multiple levels, prepay discounts, senior/student discounts, etc. We'll figure that out eventually.
- SAAS installs automatically get support bundled with their install.
- You can cancel at any time, unless you buy a "prepay for 200 years" package or whatever. It's completely fine to buy one month, ask us a couple questions, and then not renew.
Once your support plan activates, you can list features which are important to you and which you'd like to see us build (for example, SAML support, workboard triggers, or a fun video game where you can fly around in a starship). Your list might look like this:
- T8236: `arc weld` should do something
- T9900: Figlet does not properly render apostrophes with some characters
- T5657: Ability to rename flags
Essentially, you are "voting" for these features. You can edit this list at any time as your priorities change.
Beyond this list, you get a certain number of "mana points" each month. These will be called "mana points" until someone complains about how dumb and childish we are on Twitter. Then they will be renamed to "incident points". For $100,000,000,000,000/month, you might get 10 Mana. If you pay us even more, you'll get more mana. Mana is an unambiguously good thing which everyone should covet.
- Mana points allow you to cast powerful conjurations, like asking us support questions ("this weird thing happened on our install, how can we troubleshoot it?").
- Pretty much anything that doesn't require us to maintain something weird forever is in scope. We're happy to troubleshoot weird issues in your environment, help you write custom code, etc. Just not "add weird stuff to the upstream and support it forever".
- At the end of the month, you are billed for the next month and your mana points regenerate, up to some cap.
- Excess mana (basically, support you paid for but didn't end up using) is automatically allocated to increasing the priority of the features you want.
Prioritization will become more indirect, where features become prioritized as a result of cumulative voting across installs via mana allocation. For example, we might ship Git LFS support because "17 installs allocated 241 mana" to the feature. If this works well, we'll add some new systems (like "writing that text in the changelog") to make these relationships a bit more clear, so installs have a better sense of what to expect when they allocate excess mana and a clearer sense of how their money eventually turned into features.
However, part of the goal of this plan is also adding a layer of indirectness between the "pay money" part and the "get stuff" part, because the way the sausage gets made increasingly looks like us fixing 30 obscure SVN bugs in order to improve Mercurial support, which makes perfect technical sense but isn't really useful. So it's intentional that this will get a little less "X money for feature Y on date Z", and a little more "good things tend to happen to installs with ultra premium support packages".
Currently, this is largely blocked mostly on us writing Nuance so we can actually bill installs and track incidents. (There is a limited trial pencil-and-paper version of this support program today, but there is currently no way to apply for it.)