Bitcoin needs more full time developers?

[cdog]

I read in one of these threads that Gavin considered transaction malleability something like 11th out of the 10 most important updates and fixes that Bitcoin-qt needs. Its been known about for years but never addressed until it was exploited to great effect. Do you think the Bitcoin Foundation should pay for more full time developers, so that these known problems can be fixed ahead of time, not after someone finds out how to exploit them? Or is the Foundation better off sitting on their coins for now, or investing them in other ways like education and marketing? Im interested in hearing your answer.

In my opinion, Bitcoin is viewed as a high tech niche product/service, so to maintain appeal in this circle it needs to be perfect. People need to feel confident in the technology that its secure and safe to use: as much as the dev's notion was correct that flaws such as transaction malleability were not immediately dangerous, the fact that it eventually directly affected people with assets frozen on the exchanges and indirectly affected all BTC users by lowering its value should be sobering. Even if it will be fixed by next week, and the exchanges open and BTC goes on a rally, the damage has been done to peoples perception of Bitcoin. Its still early in this game, Bitcoin will recover in the public view but I think the software product itself needs maximum attention before the next wave of adoption so we dont have a repeat on a larger scale.   

Im not sure how many coins the Foundation has, but when you consider how big Bitcoin has become, and how much is riding on its success, even paying a princely sum for speedy development seems reasonable.

[underhood]

Well nobody stops you from making donations to the developers. Or you can make "donation pool" and then pay individual developers by work done. Bitcoin is OSS project many of you in this forum have made fortunes thanks to it, why not give some for the people who's work have made you richer.

[teukon]

People need to feel confident in the technology that its secure and safe to use: as much as the dev's notion was correct that flaws such as transaction malleability were not immediately dangerous, the fact that it eventually directly affected people with assets frozen on the exchanges and indirectly affected all BTC users by lowering its value should be sobering.

It is sobering, and that's good.  The problem was with the market getting drunk on hype in the first place.

If you want to donate to a developer then you have my gratitude.

[oakpacific]

First rule of software engineering: more man months!=better software.

[behindtext]

First rule of software engineering: more man months!=better software.

i couldn't agree more.

if there were more developers, then the core devs couldn't bask in the limelight of their celebrity without really hacking. i said this and more in a recent blog post i penned

https://blog.conformal.com/redecentralization-robust-developer-network/

it may also be worth noting that the proposed fixes to bitcoind's wallet code are insufficient to fix the real problem per

https://blog.conformal.com/transaction-malleability-no-shortcuts-allowed/

upshot with tx malleability is that _all_ wallets, not just those at exchanges and wallet services, need to properly make the identificatoin A = A' (mod mutations). half-ass solutions will not fix this problem.

[cr1776]

Well nobody stops you from making donations to the developers. Or you can make "donation pool" and then pay individual developers by work done. Bitcoin is OSS project many of you in this forum have made fortunes thanks to it, why not give some for the people who's work have made you richer.

Good point AND people can do the work themselves if they think something is an issue.  If MtGox really needed something changed to help their business, why didn't they write some code for it?

Mythical Man Month comes into play eventually as you increase the number of developers, but I don't think we are there.

[howardb]

Perhaps it's time to separate the development from QA/Audit function. There is a good argument I believe for a completely seperate group to evaluate risks, both specific and systemic, and feed into (but not be part of) the development process in avoiding them.