First we need to remove the barriers of contribution. Then we further need to provide incentives for contribution.

The barriers of contribution are basically:

1. People don't know what to do
2. People don't know how to do it

We solve #1 by planning openly.

We solve #2 by providing supportive infrastructures to make contributions easier. (In other words, dev center.)

Then we start providing incentives for contribution. First, we can bounty tasks that are in our interest. Suppose

I = money paid for a project with N discrete tasks b = bounty price for a given task

To be conservative, we apply a strict constraint that each discrete project must be profitable:

N*b < I

But in order to know the N tasks (or even that there are N tasks) we need to first plan.

P = cost of planning (management/estimation time)

So in fact,

N*b < I - P

So, to be equally conservative, we bill for planning separately; we'll suppose that we set an hourly rate for upfront planning which is greater than the hourly salary of the planners.

I(p) = P

Now we're back to

N*b < I

where I is the billed cost of implementation.

At this point, the client is essentially paying for us to farm out tasks to non-employees. Because we determined that the billed cost of implementation is strictly greater than the expenses we will pay out to implementors, we must be adding value for the client; after all, the client has paid separately for our planning and cost-setting, so at this point the client may as well sit back and wait for implementors to bill them, rather than paying us. We'll say that

V = added value for the client = I - N*b

The first added value we are providing is a single bill. This reduces the client's operational overhead. Let

o(c) = operational overhead to a client for a single bill

So in that case, since N discrete tasks will yield at most N bills (possibly fewer if a single implementor performs multiple tasks and bills them simultaneously) we determine that in the case where our added value is that of a billing clearinghouse

No(c) >= V
No(c) >= I - N*b

Of course, we ourselves also have operational overhead for billing

o(w) = operational overhead to us for a single bill

No(c) >= I - Nb - N*o(w)

To a decent approximation, we can pretty safely assume that

o(c) ~= o(w)

So, substituting,

0 >= I - Nb
Nb >= I

In other words, we'll have to pay out more money in implementations than we charge for them, so the whole thing's a wash. Alright, that means we either need to decrease o(w) by relying on economies of scale, or we need to find some other added value. The latter sounds much more appealing!

Well, one obvious place to start is that we be contractually obliged to complete the client's work. This is a good reason to pay us to do the work, rather than sitting around and hoping someone takes their money. It is also painfully obvious.

But, wait, how do we confidently commit to that contractual obligation? We do so by having expert developers on our payroll to complete the required tasks.

Okay, so now we seem to be at a thoroughly boring conclusion: we should have full-time salaried employees who work on the tasks that are required for us to fulfill the contractual obligations that we periodically make to our clients.

But, actually, this is where things get interesting. Revisiting those tasks for a minute, we've already estimated the time for each in the course of our planning stage:

t = time to complete a single task

(Presumably b ~ t somehow.)

So suppose we set a deadline for the project's successful completion according to contract. For simplicity we'll phrase the deadline as an absolute time interval measured from project start to project completion, D. We have a logical constraint

D >= N*t

Now we can simply assign deadlines for individual tasks:

d >= t

(Of course, we're maintaining an invalid assumption, for simplification purposes, which is that all tasks are of equal difficulty and value and require the same time to complete. In reality, a particular task's deadline should be greater than or equal to the time to complete that particular task.

We're also using the assumption that all tasks can be completed in parallel. For a sequence of tasks a -> b -> c,

d(a) >= t(a)
d(b) >= t(b) + d(a)
d(c) >= t(c) + d(b)

We use the blocking task's deadline, not it's estimated completion time, to reduce aggregate error.)

Well, that still doesn't get us anywhere, because the work still needs to be done. So here's a clever idea: we'll do the work ourselves, by the deadline! Now we guarantee that the work happens, and that it happens within the allotted time, so the client has reason to pay us!

Oh, wait, but now we're just back where we started.

Let's not forget about that potential pool of people besides us who might do that work, though. One of them might end up doing a task (and claiming the money) before the deadline, and then we have one less task to do ourselves!

But we still have to plan to do all the tasks ourselves, because we won't know until the deadline whether or not they'll get done by other people, and we can't just assume that they will -- because, after all, we promised that they would. So, realistically, we just end up doing all the work ourselves, and every so often someone else will duplicate the work. Worse, we may pay them for it, if they finish it before we do -- in which case we've paid for work twice! Or we may not pay them for it, if we finish it before they do -- in which case they've been cheated out of a payment for their work and will be at least partially discouraged from contributing in the future.

So maybe we can have people claim tasks -- and when a task is claimed, everyone else (both within the organization and outside it) knows not to take it.

But that won't help, actually, because claims can be full of hot air; so it actually just makes things worse by introducing misinformation and uncertainty into the system. That is, unless we contractually require that the work be completed if claimed -- but then contributors have a strong disincentive (in the form of legal obligation) to claim tasks and we're back where we started again. Okay, so we can't solve this by communicating claims.

What we can do, though, is fudge the deadlines. Going back to that

d >= t

We can break it up into two deadlines: a volunteer contribution deadline and an internal completion deadline. When the volunteer contribution deadline elapses, we remove the bounty from the task, but it is not until the internal completion deadline that we must complete the task in order to be on schedule.

d(v) = d(i) - k

To be clear, we now have two interrelated variables available to configure:

1. Adjust the internal completion deadline d(i). This, of course, is done by padding the individual deadlines and therefore padding the overall deadline, which floors at N*t but has no strict ceiling. Market competition for contracts provides a ceiling-like pressure, though.
2. Adjust the offset k. If we want to be perfectly conservative with our scheduling, we would not even begin working on the task until the volunteer contribution deadline has elapsed. Essentially that would require that we pad the internal completion deadlines to be twice as long as the actual time required to do the work. Presumably market forces will make this untenable in many cases, so we can instead choose to begin internal work on the task before removing the task's bounty, at the price of increased risk of "doubled cost."

Okay, this is good. Now we are clearly adding value to potential clients in the form of contractual commitments, which means that we can charge our clients more than the strict sum of the implementation costs of the individual tasks in the project. (How much more? I'm not sure if there's any good way to determine this other than throwing guesses in the air and hoping market forces correct us gently.)

And, given a particular project income, we can even adjust our profits by adjusting the deadline variables. For example, suppose we decide to be perfectly risky, by setting the overall project deadline to the precise sum of the individual task completion times, and setting the offset k to be the full length of the task. Then, in the worst case, no external contributions occur, and the project is completed in D + k time, whether by sprinting before the deadline, or by risking legal penalty, or by suffering loss of reputation for delivering late. (These all map to some additional cost shouldered by the organization, reducing profits.) But in the best case, external contributions take care of all of the tasks in the project, and we deliver the project on time without doing any of the work.

More straightforwardly, we can also adjust our profits by adjusting the bounty function. This is actually not so straightforward, though, because the equation is more complex than usual. Normally we would have market forces exerting upward pressure on bounties, balanced by our self-interest for maximizing profits. (One of those market forces would be in the form of PR; if we have a reputation for stinginess among the contributor pool, we would be less likely to get those cost-saving external contributions, and we might lose potential clients through that negative reputation.)

But in this ecosystem, high bounties don't just prevent harm done to the organization; high bounties may actively benefit the organization in the future. In other words, bounties are organizational investments. This is for four reasons:

1. High bounties attract more and better volunteer contributors for our bountied tasks. Better contributors increase the quality of the implementation we give to our clients, allowing us to raise our rates. More contributors increase the likelihood of others doing the work for us, reducing internal costs for implementation.
2. High bounties attract more new contributors for the software project in general, because new contributors will be attracted by the prospect of gaining enough domain-specific expertise and reputation to take on our bountied tasks. This actually allows us to reduce the number of bounties and provide more striations of bounties, because more tasks will simply be done by the community out of individual self-interest, and we can provide relatively greater incentives for the more difficult work and the work that has less general-purpose applicability. (This same logic provides an argument for working within open source communities in general, by the way.)
3. More and better volunteer contributors result in a bigger software community. Thanks to the empirical argument for open source software, this increases the quality of the software in question and therefore strengthens our portfolio of expertise, allowing us to raise our rates. (This assumes that the software community remains healthy, which is one reason we should build strong infrastructure for open source community maintenance, governance and management, i.e. the dev center.)

3.5) Bigger and healthier software communities increase the demand for our services, because the software is well known, well liked and widely used. (This assumes that software communities grow because demand for the software grows, which we will partially ensure through the market forces bearing on our contract choices, and which we will partially influence through investments in marketing for the software communities as distinct from the organization. A better guarantee, however, is provided by adhering to "reality-driven development" and holding the real world use cases and problems at the forefront of our minds when building software.)

4) A large, healthy software community with many high-quality contributors whose work we know intimately and who have a history of reliable, quality contributions to our contracted work increases competition for our bounties, allowing us to reduce bounty prices! It also increases our hiring pool and puts pressure on our salaried employees to remain competitive with volunteer contributors -- meaning (roughly, and in the most heartless possible scenario) we always have the best contributors on the payroll, and allows us to reduce salaries.

At this point it's interesting to consider what our salaried employees actually do. In fact, in the ideal scenario, our implementors are also our planners. The simple reason is that domain-specific knowledge is required for reliable planning. But it also allows us to take on overlapping contracts with extremely low costs -- since we're spending our "idle" time (the time spent waiting for potential volunteer contributors) billing other potential clients for our planning and estimations. So we actually want our salaried employees to be expert domain-specific planners, and the best-case scenario is one where 100% of our employees' time is spent in the planning stages, with implementations provided by volunteer contributors.

(Now imagine for a moment that we apply the same chain of reasoning to the planning process itself and open/crowdsource the planning stages. This is an interesting idea, assuming it's implemented non-recursively, but I'm not sure is there are any real benefits to justify the complexity -- at least until a competitor starts doing it.)

(And speaking of competitors, I think they're actually not bad for us. Because competitors to this organization are organizations which are competing for open planning contracts and setting their own bounties on tasks. Why? Because "closed planning shops" won't be able to compete with our efficiency, and open planning shops that don't set bounty-like incentives are just broadcasting their plans with only negligible benefit to themselves. But a competitive environment of open planning shops strongly benefits domain-specific implementors by increasing the volume and ultimately the cost of bounties -- so if we find ourselves being outperformed in the planning department and aren't getting contracts, we just start implementing against other companies' bounties!)