Upcoming Support Product / End of Paid Prioritization
Closed, ResolvedPublic

Description

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:

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.)

Details

Commits
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
Restricted Differential Revision / Restricted Diffusion Commit
D18188 / rP301750f6e692: Add an after-purchase hook to subscriptions in Phortune
Restricted Differential Revision / Restricted Diffusion Commit
There are a very large number of changes, so older changes are hidden. Show Older Changes

I've just removed mentions from Consulting, but that should eventually be updated when this is formally available.

chad added a comment.May 5 2017, 11:02 PM

Ugh, so I have to come up with reasonable arguments now instead of just paying for features?

Not at all! You can just buy an extremely expensive personal support plan and continue controlling 100% of the roadmap based on personal whim!

avivey added a subscriber: avivey.May 6 2017, 12:27 AM

I think that @epriestley just made capitalism and socialism obsolete by re-imagining everything in terms of Mana points. You sir, have won the internet.

I was fully expecting a black market for mana points to be available.

We might eventually support a trade/resale market -- one advantage is that we could give contributors something with slightly more valuable than stickers/flair/badges, but less complicated for us than doing fulfillment on schwag or dealing with taxes for actual money.

Then we just need collectable trading cards and loot boxes and we're off to the races.

phabricator trading cards ftw.

NDKilla added a subscriber: NDKilla.May 9 2017, 1:46 PM

If I read this correctly, people would pay a certain amount regularly without any certainty or reasonable expectation to have any of the fixes or support they care about. Instead they'll need to rely on the resident haruspex to assess what they're embarking on.

This looks more like donating than like buying a service. That's ok; but there are established methods to manage such things, usually involving a non-profit entity which accepts members and where members get some voting/decision-making privilege above some threshold of contribution (but you could also call it a donor council or a sponsorship with benefits).

epriestley added a comment.EditedMay 17 2017, 11:25 AM

@nemobis, can you walk me through the major differences you see between the proposal above and the support plans offered by other vendors like GitHub, GitLab, and Atlassian so I can make things more clear?

The intent is that you are buying a service extremely similar to those services, except that there is a stronger link to feature development than those services offer.

jcox awarded a token.May 17 2017, 11:47 AM

This looks more like donating than like buying a service. That's ok; but there are established methods to manage such things, usually involving a non-profit entity which accepts members and where members get some voting/decision-making privilege above some threshold of contribution (but you could also call it a donor council or a sponsorship with benefits).

Also, what you've described here is basically just "taking money from VCs". If it was possible to "donate" to this project to get voting / control over decision making, I think all of those votes would immediately be bought by VCs and they would control the project from that point forward. Currently, we routinely turn down opportunities to cede control of the project in exchange for investment funding, and I expect to continue to do so in the future.

Sorry, I'm unable to answer your question because I have no idea how you could compare development support to hosting services, or equity to donations.

chad added a comment.EditedMay 25 2017, 4:08 PM

We're an evil, for profit company. I'm not sure what's confusing about that.

Indeed I'm not confused about that. That's why I pointed out that giving money in return for no right/expectation to anything, AKA donating, is usually something done towards non-profit entities with certain requirements, not for-profit entities.

Perhaps I missed some implicit premise of this task, given the weird reference to Gitlab/Atlassian/GitHub hosting. Are you perhaps implying that you mostly/only want to sell services for the customers of your hosted solutions https://www.phacility.com/pricing/ , while self-hosting users would need to pursue some other method to facilitate Phabricator development?

chad added a comment.May 25 2017, 4:19 PM

We're planning on selling enterprise support contracts, like those you can purchase from other self-hosting providers like GitHub, Gitlab, and Atlassian. You are not donating money to Phacility.

@nemobis: when customers pay (for example) Atlassian for Atlassian Premier Support, what value/right/expectation do you believe they're getting out of that which we aren't also offering above?

chad added a comment.May 25 2017, 5:50 PM

Well, it is worded very playfully and not very serious corporate business-like.

I feel like there's just some kind of bizarre disconnect:

epriestley: In the future, we're going to start selling apples for $1 per apple.
nemobis: I have an apple tree that I can pick apples from for free. Why would anyone pay for apples? Did you mean to start a non-profit charity to plant apple trees?
epriestley: How is our proposal different from the hundreds of existing supermarkets that already sell apples?
nemobis: You can't compare them, one is an tree and one is a store. Your question doesn't make any sense.

@nemobis - um, you've ever been in enterprise software dependent business? I do consulting for companies that pay thousands euro per year per single solution (having 5-10 is norm) and within that they get sometimes as much as "3 free support ticket" or "50 free support tickets and 3 voting points for features". I personally developed some back-end solution to deal with one problem that started happening in version 4 of one software and got fixed after ~6 years. In version 10. why? because "this problem impacted only 17% of our customers and can be fixed manually. to have fix developed specially for you, pay us ~20x as much as you pay per yer per licence". And that.is.considered.normal.

Now what we get from Phacility is absolutely heavenly.

um... Phacility High Command - i ❤ you! Plz don't go enterprise-software all-the-way!

urzds added a subscriber: urzds.May 26 2017, 2:46 PM
epriestley added a revision: Restricted Differential Revision.Jun 28 2017, 12:21 PM
epriestley added a revision: Restricted Differential Revision.Jun 28 2017, 1:06 PM
epriestley added a revision: Restricted Differential Revision.Jun 28 2017, 2:00 PM
epriestley added a commit: Restricted Diffusion Commit.Jun 28 2017, 6:04 PM
gou1 added a subscriber: gou1.Jun 29 2017, 4:22 PM
epriestley added a revision: Restricted Differential Revision.Jul 5 2017, 10:49 PM
epriestley added a revision: Restricted Differential Revision.Jul 6 2017, 12:25 AM
alexmv added a subscriber: alexmv.Jul 6 2017, 12:28 AM
epriestley added a revision: Restricted Differential Revision.Jul 7 2017, 6:27 PM

Notes for myself about billing:

You can create a pact without specifying a billing method, since if you're bartering trinkets we need human involvement. So the flow is:

  • Pick a pact type.
  • Provide details (name, etc).
  • Pact is created in an initial "bartering" state where payment is due. The "bartering" state serves as a welcome state for first-time pacts with setup guidance.

At this point, the UI should guide you toward executing payment if the pact is a billable type (vs bundled support for SAAS instances). The rules here are a little different than the rules for instances:

  • You can't accumulate unpaid invoices: if you have an outstanding invoice, we shouldn't generate any more (we just don't deliver service during unpaid periods).
  • When you pay an invoice, we should reset the trigger clock on the subscription to the current time. For example, if you let a pact lapse for 10 days and then pay, you get a full period starting from that date. We don't do this elsewhere and it may be a little messy, but should be tractable.
  • We probably still want to do all the CC billing under a single subscription still, so there's a single set of records in Phortune.

For non-CC billing, I'm going to direct you to open a support ticket explaining how you're planning to pay us so we can move forward.

Once you make a CC payment or offer us a pouch of coin, your pact gets kicked into an "active" state and things go normally from there.

For recurring billing, I think we want three states: Do Not Renew, Credit Card, or Invoice. These mean:

  • Do Not Renew: Your pact will remain active for however long you've paid for, but will not be renewed after it expires.
  • Credit Card: We'll generate a credit card invoice using normal subscriptions after support expires. If you've configured auto-pay, this will automatically re-up.
  • Invoice: We'll manually hassle you when your next payment due date approaches, or just send an invoice or whatever else was agreed upon based on your organization's unique billing process.

Actually I suppose these states aren't really exclusive, I think "do not renew" is probably just a separate flag and users don't need direct access to "Credit Card" or "Invoice" since they can/should just open an issue if they need to swap stuff. We could let installs swap from "Invoice" to "Credit Card" without our involvement, technically, but this will presumably almost never happen.

In terms of actual active state, I think we just store a paidUntilEpoch, manually set this when we receive a pouch of coin, and automatically adjust it when processing a card payment.

I don't plan to ever prevent you from filing issues, even if your pact is new, broken, or mana-drained -- so you can always get support to reactivate it -- although we may eventually need a state which explicitly terminates a pact (i.e., no longer writable). I'm not concerned about this for now, though. The UI will just clearly show issues associated with new and dead pacts (and mana-drained pacts) and sort/filter them appropriately. But operations with mandatory mana costs (e.g., buy t-shirts for mana or throw your mana in the mana bonfire or whatever) won't work when executed from broken or drained pacts.

I'm also going to install a daily trigger on all pacts as a place to do general maintenance operations like mana regeneration, state transitions, reminder emails, etc.


I'm going to reserve pact type changes for staff for now, too. We could let users upgrade/downgrade their pacts themselves, but this is a little tricky to do in a totally fair way without being crazily exploitable -- and presumably also quite rare, and probably every one of these is ultimately some weird special case. We can let instances swap types freely since there's no real exploit pathway but you can easily dupe SoJs on support pacts by swapping plans around.

epriestley added a revision: Restricted Differential Revision.Jul 7 2017, 11:30 PM
epriestley added a revision: Restricted Differential Revision.Jul 10 2017, 7:42 PM
epriestley added a revision: Restricted Differential Revision.Jul 10 2017, 10:10 PM
epriestley added a revision: Restricted Differential Revision.Jul 10 2017, 11:53 PM
epriestley added a revision: Restricted Differential Revision.Jul 11 2017, 6:56 PM
epriestley added a revision: Restricted Differential Revision.Jul 12 2017, 1:57 PM
epriestley added a revision: Restricted Differential Revision.Jul 12 2017, 7:10 PM
epriestley added a revision: Restricted Differential Revision.Jul 13 2017, 10:29 PM
epriestley added a commit: Restricted Diffusion Commit.Jul 14 2017, 2:35 PM
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.Jul 14 2017, 2:37 PM
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.
epriestley added a commit: Restricted Diffusion Commit.Jul 14 2017, 2:45 PM
epriestley closed this task as Resolved.Jul 14 2017, 3:14 PM
epriestley claimed this task.

This is entering some kind of closed beta shortly, I'll follow up in T12904 for actual feature improvements to the Support application.