Page MenuHomePhabricator

Formalize Paid Prioritization?
Closed, ResolvedPublic


I'd like to explore developing a more open paid prioritization flow -- specifically, something that says "this is what we offer, how it works, and how much it costs". I think the two major issues we see today are:

  • There's a lot of overhead in contract setup, which is bad on both sides.
  • Stuff stalls on customers, who are generally less nimble than we are.

I'm not sure we can really fix (1), since engineers are usually the ones who want features and they don't usually have permission to approve expenses, but I think there's a good chance that we can reduce the amount of overhead we deal with by pushing the service toward something that looks more like a commodity. Ideally, the process would be something like buying a new monitor and expensing it.

I'm sure we can't fix (2), but we can try to push more of that cost back onto customers so we aren't stalled.

At least some of the contract setup cost is aimed at protecting the parties from risk. Our service already exposes customers to very little risk, and we can eliminate more of it. In particular:

  • Disclosure Risk/NDA: We don't normally have any access to private data anyway, and generally don't want this access.
  • Nonsolicit/poach: I think we can offer this in a blanket way to anyone who pays us for anything (I believe we don't ever care about it, but we should be more clear about exactly where the monopoly/antitrust stuff kicks in before we offer a button that you click to stop us from hiring your employees).
  • IP/Work Product: We always own all our work product. We've historically needed to strike this section out of contracts anyway.
  • Nondelivery/Acceptance: I think this is the notable part: we can eliminate this risk completely. Basically, this amounts to a "if you aren't happy, don't pay us" structure. Specifically:
    • We have plenty of buffer relative to the size of projects (which are maybe a month long at the very outside), and we can always accept payment on delivery.
    • If customers bail/flake, we don't lose very much. We still own our work, and it's always stuff we would have built anyway and are willing to maintain.
    • If customers aren't happy, we can just decline to accept their requests in the future.
    • Since we choose what we accept, we can balance this for new customers with large requests.

Ideally, that would let us get paid prioritization structured in a consistent way that can be made relatively public, which could eventually help with (2) by exposing the queue and making the rules around the queue automatic and clear ("if stuff blocks on you for X time, your stuff falls down the queue").

Here's a very rough draft of what this might look like...

IMPORTANT: This is a draft, not a policy we've actually adopted yet!

Paid Prioritization

If you'd like to get a specific feature built right away, Phacility offers paid prioritization. The service we provide works like this:

  • We'll prioritize a feature you're interested in and build it as soon as possible.
  • We'll charge you $150/hour for the time we spend working on it.
  • This service is risk-free. Payment is not due until delivery. If you aren't completely satisfied, you aren't expected to pay us.

What Can Be Prioritized

The service we offer gives you control over our development priorities, not access to custom development. Everything we build will go into the upstream and be released as open source. We'll retain ownership of all our work product and intellectual property. In exchange, we'll maintain the feature in the upstream indefinitely, for free.

Because we're committing to an indefinite maintenance window, we're only willing to prioritize features that reasonably fit into our roadmap. If you have a very narrow use-case which is specific to your organization, this may not be a good fit for what you're interested in. Fortunately, our roadmap is vast and most of the features users have ever requested fit into it. For example, almost everything in Maniphest is suitable for prioritization.

Risk Free

Payment is due only on delivery. If you aren't completely satisfied with the product, timeline, price, or any other aspect of the service, you are not expected to pay us.

This is an unusual way to structure service offerings, but aligns well with how we provide services. Specifically, the cost of negotiating, reviewing, and executing contracts is far higher for us than the cost of accepting all of the delivery risk.

Getting Started

If this sounds like something you might be interested in:

  • Send us an email at describing the feature you're interested in prioritizing (usually this is just a task number from Maniphest).
  • We'll give you a rough quote and timeline, and discuss any considerations relevant to the specific feature you're after.
  • If those sound reasonable to you, we'll prioritize development.
  • After we ship the feature, we'll invoice you for the time we spent developing it.
  • Pay the invoice only if you're completely satisfied with the service, timeline, price, and product.

IMPORTANT: This is a draft, not a real policy.

Phacility Prioritization Service Agreement

This document describes the prioritization service we offer. We want to make sure your expectations are clear before we agree to prioritize work for you.

Paid Prioritization

You may offer to pay us to prioritize the development of certain software features. At our discretion, we may accept your offer. This process is informal and does not create an obligation for either party: we have no obligation to deliver the work, and you have no obligation to pay us.

We Own Our Work

We own all the work we produce and retain all of the intellectual property rights. We will release the work as part of the Phabricator upstream, under the same open source license that Phabricator is normally available under. This will allow you (and all other users) to benefit from the work. We do not offer custom or closed-source development services.

No Warranty

As the work becomes available, you (and all other users) may use the work in accordance with the license. Paying us to prioritize work does not grant you any special rights to the work, and does not imply any additional warranty. Your rights with respect to the work are dictated solely by the software license and are no different from the rights of other users.


We will maintain work we produce indefinitely, without cost. We will decline work which we believe we can not maintain indefinitely, unless we reach an agreement about the lifetime of a feature.

On rare occasions, unforeseen events (including changes in our plans for the product) may affect our ability to maintain a feature, and we may remove features from the product, including features we have prioritized for you. If we do, your only recourse is to continue using an older version of the product which included the feature.


We will often estimate the cost and timeline for services before rendering them. These estimates represent our best guess, but may be unreliable. These estimates are non-binding and create no obligation.

Pay Only When Satisfied

Payment is not due until delivery. If you are not completely satisfied with the any aspect of the service (including the product, timeline, price, or anything else), you are not expected to pay us.

Related Objects

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added subscribers: epriestley, chad, btrahan.

I don't know if this would actually lower the barrier enough to meaningfully impact the kind of contract work we see, but it seems like it wouldn't cost us much to put this out there.

I think both sides benefit substantially if we can push this transaction to be like "buying a laptop" instead of "two companies getting married forever".

chad added a comment.Mar 31 2015, 4:53 PM

Should we have this as a public doc on Phacility we can point to?

If we adopt this, I'd plan to make it a public doc, yes.

chad added a comment.Mar 31 2015, 5:46 PM

I'm up for trying anything, this is mostly your time taken, so happy to support whatever. I like that it says, we're just honest folk trying to do the right thing.

This seems great to me. I think we run the risk of running out of bandwidth pretty fast though. How do things work if / when that happens?

chad added a comment.Mar 31 2015, 7:39 PM

Are there employee discounts?

Employees get a free pre-paid card and instant premiere status (fancier looking bill), but still full price.

Like hologram stickers fancy?

I think we run the risk of running out of bandwidth pretty fast though. How do things work if / when that happens?

I think we raise our hourly rate if there's too much demand for the available supply.

qgil awarded a token.Apr 6 2015, 6:29 PM
qgil added a subscriber: qgil.

I'm going to clean this up a little bit and publish it as policy and we can see where it goes. It's possible that there are essentially zero customers who are authorized to spend $150/hr without going through a contract/approval process, in which case I'll have wasted a couple of hours, but if we convert even one protracted contract negotiation over to this reduced overhead system it pays for itself immediately.

epriestley closed this task as Resolved.Apr 10 2015, 11:22 PM

Formalized here:

I wordsmithed a bit and added a "we'll try not to tell anyone who you are if you're being sneaky" clause to make it clear what information we consider private (who is paying us) vs public (basically everything else).

qgil added a subscriber: greggrossmeier.EditedApr 11 2015, 7:28 PM

I have posted the a request for paid prioritization in a short list of open tasks that I (and probably @greggrossmeier ) would be happy to ask budget for. Maybe we at Wikimedia can find some funds for small bites in this quarter, maybe we can go for larger bites for the next quarter / fiscal year starting in July. Maybe.

About the lean process for estimate quotes and then do the work, it is interesting to say the least. I think it can work with us, as we have some flexibility with estimates and actual costs, as long as things don't go crazy. I like the balance of risks: customers risk being invoiced more at the end, you risk not seeing any money at the end. Balanced trust?

Thinking about it, I imagine we'll never actually bill above an estimate (at least, without some kind of confirmation/approval first based on new information). We should possibly just make that explicit, although I'd like to keep things as simple as possible and there's already a remedy available: don't pay us.

In any case, you can reasonably expect that the estimate is an upper bound, and if we send you a bill which is larger than you were expecting we'd anticipate you being dissatisfied and declining to pay us. Our intent is to assume all of the delivery risk that we reasonably can.