Devtome: Suggestions for Improvement

This article was first posted here and the conversation continued there with some points clarified.

I believe discussions around a particular aspect of Devcoin reward; writing or programming or bounties are peripheral to the bigger picture. And it's the bigger picture this article looks at. Whether party A or B receives DVC isn’t necessarily relevant because both have equal optionality in what they do with their coins. So there’s no point just looking at Devtome.

Economic incentives

In the example of the catalyst for this article - bounties for suggesting improvements - what’s the problem? Is it double-dipping, overpaying or just a question of why do good ideas that would be mutually beneficial to those suggesting them need to be paid for at all? Perhaps this engenders exactly the wrong approach and stilted progress. In this case, why does it take a bounty for people to submit suggestions on how to promote, display, improve their own work or increase their own compensation’s value proposition? Would the same result be achieved without payment? If not, why not? These questions of economic incentive need to be considered for Devcoin in general, before assuming any return to further efforts, if nothing happens without such incentive.

Interest incentives

What are the natural Devcoin interest groups. In my opinion (considering the realities of what Devcoin rewards today) it is:

a) Open Source Developers;
b) Creative commons Writers;
c) Those who value the above;
d) Those who just dream of making loadsa money on cryptos

I don’t think the current setup appeals ideally to any of those subsets, yet. As far as I can tell, most open source developers and writers are not only motivated by monetary reward, and punters are only motivated by monetary reward. Having a system that rewards first on the basis of output and second on the basis of initial motivation and final value seems to run counter to a), b) and c). It also runs counter to d) because it undermines prospective returns. It might therefore explain a broad reluctance to get involved in Devcoin.

Devcoin suffers from a big free-rider problem. That doesn't mean all writers are free-riders, it's a term to describe a misalignment of input and reward. A one way street. It's a simple reality of many aspects of life, in that it just reflects interactions and people. But it doesn’t work here because the way Devcoin differentiates itself from other concepts is an implicit rejection of the free-rider dilemma; that reward is in return for work. So if consenus thinks problems are reflected in a 'wrong' price then in turn something’s going wrong with the relationship between effort and reward. Otherwise, the price is a fair reflection of everything.

But let's say this perspective is totally off. Then who is Devcoin trying to appeal to? Is producing open-source output behind a compensation gate the same thing as producing open-source output for the sake of open-source. i.e. what comes first, the effort or the return? The progress of wikipedia, linux etc may involve paid employees but getting from there to here also involved a lot of people who just wanted to get it done and have been willing to contribute time and effort. Are we actually claiming to have reinvented the open-source wheel - that Devcoin overrules everything that has come before in terms of aligning motivation with results? I'd suggest this is Devcoin's major fault.


I have also benefited from this system. But if we want to progress then it needs to change. If not then we need to stop grappling for movement while ignoring the bigger underlying conflicts. Does that involve greater subjectivity? Perhaps. Alternatively we could just apply a simple test of whether efforts would be first valued in their own right without paying. That doesn't mean there is no payment, only a consideration test.

That could lead to one of two scenarios. (1) nobody would contribute. The inference being that participation is about monetary reward rather than valuing efforts; or (2) contributions would continue, inferring the opposite. There’s obviously a middle ground of just reducing reward until there’s an obvious transition from (2) to (1). This discovery process is important because Devcoins are a limited resource. What is spent in one place cannot be used elsewhere.

That still leaves the issue of what or where Devcoin resources should be targeted. Just eliminating or cutting bounty/devtome/developer share payouts doesn’t address the issue of distribution. So how would I start dealing with it all:


  • 1) Bound Devtome ratings between 0 and 1, with a minimum multiplier of zero. Ensure every writer has at least one rating before any payout. That may require a longer period between submission and pay.
  • 2) Iteration. Take the implied $ value of a writing share at the end of a payment round and plug it into the next earning round. Keep doing this until there’s a more obvious point (near equilibrium) where implied value is clear. i.e. if the value of writing 1000 words is $X, adjust the next round’s compensation to reflect that $X. Yes the price varies, and yes taking the end of a round value is arbitrary, but it’s a start. This does not raise the price but it could stop it falling once the iterative result is clear. An alternative to this is to make all Devcoin earnings equivalent in per hour or another per effort measure. That way there is no one endeavour that determines the reward for all others.
  • 3) Cut max payout (not max word limit or any limit on roll-over) and spread out earnings over several rounds, to dilute price-setting power and encourage new writers via a bigger pot. That means a greater number of people with a more equal interest in longer term progress. If only to discover the breakeven level for real interest. This would increase the number od DVC per share and work in the interest of most writers. It would also mean the better writers still receive all compensation but over a longer period, tying the interests of the project more with the most committed and skilled, and less with the opposite. This may not be necessary if all prospective earnings were equivalent, as above.
  • 4) Incorporate a script in Devtome that checks whether articles are listed on any page (category, front page) other than the writer’s own. Factor this into payout. This may give a better idea of submission motivation. If writers aren’t interested in readers, evidenced by just listing article on invoice page and waiting for payment, why should anyone be interested in them.
  • 5) Stop paying for content that exists elsewhere. Blog, book writings are great, but if they’ve already been compensated via traffic or other means, paying again creates an economic mismatch. If I've already been rewarded for an effort - be that in monetary terms, educational accomplishment or just acclaim - paying again assigns an implied value that's much lower (maybe zero) on that effort. If it goes on devtome and is paid for, it should only be on Devtome. Otherwise it should be unpaid. I’d be interested to see that tested - how many would submit writings exisiting on other own sites for no reason other than content sharing? Alternatively, if the point of this is to drive traffic and page views then this should just be admitted and justified.
  • 6) POS. Incorporate something like Diedicar’s suggestion. I don’t know if it would work interms of incentives, but it’s quite an elegant system if you take some time to understand what he suggests and certainly works as a mechanism. It builds from the same hypothesis as this article; that either increasing contributors or equivalent reward are required for growth and sustainability.
  • 7) Rejig the Devtome frontpage and supporting info articles to emphasise Devcoin and it's project aims of Open Source and community, rather than an employer-employee relationship. The vibe is quite different.
  • 8) Where possible add plugins to improve visuals and navigation (this requires proficiency in PHP and an ongoing commitment). Some have suggested having specific blogs focusing on particular ares, for example cryptos. Instead, this could be done via the front page - structuring it in a way that better highlights/links to different areas of focus - even including blog-like pages. This requires community mutual trust and delegation to those with specialist skills. However that is entirely what Devcoin is about so encouraging responsibility and accountability is a positive.
  • 9) Incorporate a page or area that aims to directly tie together writers and developers. Quite a bit of developer talk is not simple to understand. Devtome is a repository for people who have something to say, and some say it better than others. If developers could utilise the communication skills of writers in docs or POC or just a narrative this would help simplify their concepts for a broader audience, while also building the knowledge of those with an arts background to the developer's aims and perspective.


  • 1) Where paid bounties can be justified on the basis of efforts and contribution to others’ interests, then pay. Otherwise don’t. i.e. ensure they're community based.
  • 2) Price bounties before awarding them. If something’s considered to cost $100 to get done then make the bounty equivalent to $100. If the dvc price falls between announcement and reward it’s probably fair to assume that consideration of such effort (and others collectively) is not in line with the assumed plan. While this might seem harsh, I can’t see how else we discover what people are really interested in. This pricing must be on the same basis as writing and development and anything else. If 4 hours work = 1 share, then 40 hours work should equal 10 shares etc. Otherwise interest stalls.
  • 3) Focus more bounties on doing rather than suggesting. For example everybody seems to agree that devtome needs improved visuals. So it would probably be better to channel payouts to those who can implement rather than talk about it (like me).
  • 4) Offer bounties on the terms of the OS developers/writers/artists/musicians, not Devcoin. This spreads 'control' of a project or bounty to a wider group of expertise. So if, for example (and optimistically) a significant OS project proposed assistance with something, we could defer the power to apportion the entirety of that bounty or generation shares to their discretion. I say this because there are at least 3 obvious barriers to getting the word out. Evidence, trust and effectiveness. Doing this would build all 3.


  • 1 ) Is this a client-customer relationship or a mutual endeavour? The two are not the same. A turkey (customer) will not vote for christmas whatever the appeal, so this needs deciding or nothing will move forward. To explain more fully: We have a system where admins, those with most influence to promote or avoid change, are primarily drawn from writers/developers and then from the most prolific writers/developers. If the relationship is client (Devcoin) and customer (writers/developers) it is in the interest of Devcoin recipients to maintain a system where they accrue most financial benefit. That's the terms of the status quo deal, so to be expected. But it creates a conflict of interest because decisions will be influenced by the risk of harming self-interest. This is acceptable so long as everyone understands the state of play, that compensation is largely determined by a minority with most to lose from changing it. By 'mutual endeavour', I am refering to a way of limiting this risk in such a way that gives all participants more equal input into decision making and prevents stasis being maintained under an illusion of optimality. How this is done is a matter for everybody to decide, but may include more broad voting input.
  • 2) Make all contributions equivalent. If writing share per effort unit (time or whatever) < developer share that also doesn't work. As above, contributions should be assessed not on the basis of favouritism (writing or developing) but effort. If writing 1000 words takes, for example, 4 hours there is no logical basis for paying developers 1 share for 40 hours work. This is the prime reason for lack of developer interest. Devcoin has established something great with the concept already demonstrably aligned to work. However prices are a function of an unlimited contribution by one subset. This price setting is a limit on growth of price and interest. Rather than perceiving differences between contributing work and art forms, we should start everything from the first principle that reward must be equivalent to effort. Once that is firmly established, the natural course of progress can be what we make of it rather than limited by preferences. Aligning payments with all earners should appeal to more developers and writers, increasing the numbers of Devcoin earners and in turn appeal to more developers and writers etc.
  • 3) Decide how best to 'reward open source developers'. Enough time has passed to conclude that just waiting for developers to find and like Devcoin isn’t working. Options here might include group voting on particular project funding. E.g. FreeBSD recently asked for funding help. We ignored it. I don’t use it so not in a position to appraise, but perhaps we should be asking ourselves what it is exactly that Devcoin aims to achieve.
  • 4) Subsidies such as the one for Devtome is a nice idea when assessed in the context of potential revenue generation and interest, but it needs some serious rethinking. The reason it's not working as expected is because unlike fiat and taxes Devcoin is optional. Economically subsidies reduce the cost of supply. Which means price is not equal to production cost, which means the price falls because more can be produced at a given price than the market demands. This shifts the supply curve towards a lower price intersection with demand. To where we are now: Because there's no cap to Devtome’s share of total generation all Devcoin value derives from it. Only when there is a self-sustaining contributor and content base (not just transience) does financial self-sustainability become something to work on. If the basic infrastructure is right the only limit to appeal and impact is what people make it.
  • 5) Get over ourselves on the payment mechanics. Devcoin is one of hundreds of alternatives. If the restriction to acceptance is lack of a Devcoin client or reluctance to install one, who loses out. Them or us? Yet the result to date is the same: DVC → Fiat. So until there’s a simpler transmission means, shouldn’t the net reward trump the mechanism. Again it comes down to question of what’s it all for? Yes there’s a risk it undermines DVC as a payment, but is it any more undermining than current inertia? Just look at how many Devcoin 101 questions are asked Devcoin recipients, let alone those we hope will get onboard. Rewarding projects from a starting point of Devcoin's proactivity may create greater interest and growth than waiting for others to mould themselves to what others perceive as overly complicated. Therefore, we need to get more developers and projects on the lists. Devcoin and non-Devcoin based. To raise difficulty, to incorporate another value proposition as price-setter rather than price-follower and fundamentally because to progress in OS development for an OS-focused concept requires OS focus. This may initially require project support/donation.
  • 6) Distribution. It’s ludicrous that if I were to write 50k words I could still earn 3% of total dvc generation in a round. 50% of generation of late goes to about 10 people. Just read posts on BTC and newbie frustrations with mining difficulty, getting involved etc. Yet our distribution is even more concentrated. Either this gets addressed or we can’t stake a claim on inclusivity, or expect it. And if anyone brings up the analogy of btc being divisible into satoshis and how that means with Devcoin more involvement spreads the love, then no it does not. It still means massively uneven distribution. Which is fine for BTC because there's no alternative claim made, but not for Devcoin.
  • 7) Split generation between Devtome, Developers and other future projects as % per round. Then assign payments from each pool. This allows each group to better determine relative payout. i.e. I think better writers or developers would be far more active in dealing with lesser deserved returns if it more directly affected their own prospective returns. Alternatively they'd just stop writing or developing. Both of these scenarios would give us a better idea of what really motivates and supports Devcoin progress. Bounties are a fixed share value, so an example could be to say that post-bounties (whether that bounty is writing, programming related) we assign 45% to Devtome, 45% to Developers and 10% to pool for collaborative projects that include both. Bitcoin is facing a dilemma with concentrated mining power. What I’m outlining is the Devcoin equivalent, where concentrated distribution becomes both a psychology off-putting factor, but also a mechanical problem because a few people hold all the cards.


Price vs Difficulty

Relates to discussion starting here


difficulty2.jpg difficulty3.jpg


Round end No. of shares (difficulty)DVC per share mdvc/btc dvc/btc $ per share
round 22 10/04/2013 125 1,440,000 1.48 0.00000148 227
round 23 11/05/2013 501 359,281 1.75 0.00000175 72
round 24 12/06/2013 1277 140,955 1.00 0.00000100 15
round 25 13/07/2013 669 269,058 0.78 0.00000078 19
round 26 12/08/2013 857 210,035 0.54 0.00000054 11
round 27 11/09/2013 646 278,638 0.38 0.00000038 13
round 28 11/10/2013 612 294,118 0.37 0.00000037 14
round 29 10/11/2013 369 487,805 0.20 0.00000020 33
round 30 11/12/2013 816 220,588 0.60 0.00000060 118
round 31 10/01/2014 1243 144,811 0.61 0.00000061 73
round 32 09/02/2014 1587 113,422 0.60 0.00000060 48
round 33 11/03/2014 1938 92,879 0.38 0.00000038 22
round 34 11/04/2014 1119 160,858 0.29 0.00000029 18
round 35 11/05/2014 1002 179,641 0.19 0.00000019 15

$ per share vc BTCUSD

Start of Round:sharevsbtcstart.jpg End of Round:sharevsbtcend.jpg


ratio1.jpg ratio2.jpg


To come, when more round data is available.

Devtome | Devcoin

QR Code
QR Code devtome_improvement_suggestions (generated for current page)