...I'd say it definitely encourages lifestyle authors of written material at this point. It might also encourage people who are not using it in the spirit it was intended. But if it went to the lifestyle developer=certain number of shares, you'd probably have to have the dedicated pool of developers *first*, transition the program, then there'd be a lot fewer shares that would be worth more. You'd also theoretically be able to up the number of shares given to lifestyle developers for their work (for instance if that section in a receiver file looked like devtome earnings currently does)
One way would be to apportion each aspect of devcoin a weighting of periodic generation. For example, we might say devtome = 180m * x%; developing = 180m * y%, bounties = 180m * z% etc. Then all payments are made from a sub-pool. But the problem with that is it changes the calculation dynamics, where for example a bounty would also need to become a % rather than an absolute sum. And then, what if there are no bounties achieved in a round, does that roll over to the next month - would that help catalyse getting it done, or would it instead just be 'wasted' when it could have been earned by somebody else.
That's why I've only suggested limiting the max payout
per round - unless specifically designated like a bounty. Because if that cap is at the right level it
should result in work and pay trending towards some sort of equilibrium where all parties - writers, developers, one-off bounty workers, admins, buyers etc - think it's worth their time and effort. And in rounds where that isn't the case, the dynamics of relative interest up or down should be corrected, because anything considered too low/very high will feedback into disincentive/greater incentive in the next one.
So I think the issues and same ends can be addressed more easily with cap (and maybe floor) adjustments over time without going through the hassle (and unknowns) of adding more complications.