There’s never been a whirlwind of politics surrounding an open source project on the scale that we see with Bitcoin. Alternative implementations are considered controversial on principle, and Core devs can’t propose a bug fix without being accused of manipulation on behalf of outside interests. However, BSD, another popular open source project, doesn’t seem to have these problems. Why not?
Also read: Ethereum Node Growth Explodes on “Homestead” Release
At the same time, though, we’ve never seen an OSS project so paralyzed by community sentiment, at the cost of the functionality of the software they produce. Many would argue that this is because the value proposition of the Bitcoin specification is unique, and these problems come with the territory. That assumption has helped generate a lot of the controversy surrounding Bitcoin development, and is not only harmful but dangerously inaccurate.
Understanding Current Problems with the Bitcoin Specification
Bitcoin adoption is growing fast. We’re seeing the average block size rising steadily to reach the 1MB cap. People are quick to point to this as an indicator of Bitcoin’s health in spite of debate and userbase in-fighting, It’s also causing problems for Bitcoin developers. As it stands, Bitcoin can’t handle much more network load without adjustments.
The problem is, Developers can’t agree on how to adjust Bitcoin to help continued growth. The userbase is exacerbating this issue, creating a toxic environment for developers regardless of how they want to service the specification. The Bitcoin community has balkanized itself over differences that will be functionally the same after being committed, engendering inaction in the developers of he majority implementation for fear of alienating large segments of Bitcoin users.
Bitcoin needs to grow to support the increasing number of transactions made over time. There’s a lot of ways to skin this proverbial cat, but the community is breathing down the Core developer’s necks, attributing Freudian levels of significance to which knife they pick to start the process.
Naturally, the developer groups are finding the scaling commits difficult to complete (or begin in the case of particular implementations.) This progress gridlock is worsened by Core, Classic, XT and other codebases refusing to cooperate with each other, as a result of similar userbase pressures. The outcome is that Bitcoin development is grinding to a halt as demands on the network continue to grow, and the fear is that demand will outpace what limited improvements are made.
Bitcoin Isn’t the Only Valuable Open Source Project
Many people take a deterministic view on Bitcoin development politics. The sentiment is that financial interests make Bitcoin a high priority target for vocally negative feedback, and the intrinsic value of Bitcoin increases animosity in any disagreement. Accepting this situation as rote is dangerous, because Bitcoin is far from the only disruptive Open Source Project With a lot of Financial and Enterprise interest. It is the only one that lets it’s users hurt its development and evolution for the sake of appeasement, though.
There are a few changes in methodology Bitcoin developers can take to stop the current gridlock from spiraling out of control, and the development community that models these changes is over 30 years old and has been doing things the same way for nearly as long. They’ve enjoyed long-term, sustainable success in the enterprise community, and their code runs on billions of devices. I’m describing the developers of BSD, and Bitcoin devs need to imitate them, and start soon, if they want to ensure the long-term success of Bitcoin.
Not familiar with BSD? That’s perfectly understandable. They’re only championed outside the enterprise and server use cases by relatively small communities of enthusiasts. If you use, say, Netflix, Yahoo, WhatsApp, run a home NAS, play games on a PS4, use a Mac for your daily driver, or use Microsoft’s Hotmail service, you use BSD code every day. BSD has a nontrivial amount of corporate interests that have a vested interest in BSD development. I’d be willing to bet it’s much more than the amount with a direct interest in Bitcoin.
BSD also has far more forks and varying implementations than Bitcoin, and they work on code orders of magnitude more complex than the Bitcoin devs. All of the dominant flavors are binary compatible, and development moves forward on schedule regardless of arguments in the user-base and pressures from people making money off of their codebase.
Outline of BSD Commit Structure
They’ve been doing what they do sustainably for ages, with each different flavor contributing across community borders and working towards an ultimate goal of increased adoption and a stable, high performing product. You can see these goals increasingly failing to be met in the Bitcoin development space, and the consequences of falling behind are becoming increasingly serious for everyone using the Bitcoin protocol.
Conferences and Summits have come together trying to change the direction of this trend, with little to no effect. The reason is that the only people that can fix the problem are the developers of the Spec, and the problem primarily lies in their design and commit philosophy and/or lack thereof.
Currently, Bitcoin development mirrors the relative chaos seen in the Linux-style OSS development space, which lends itself more to quicker, albeit less stable project evolution. However, we’ve seen Bitcoin Core development slowed to a standstill. That, combined with a lack of inter-contribution, makes this stagnation a problem. This is because of the development philosophy and lack of a structured development and commit system. Individual developer interests should be less impactful on the project as a whole, and the best solution for each problem would be implemented ASAP if they had a good way of sorting out how their code is developed.
What Bitcoin Devs Can Learn From BSD
First and foremost, the way code is developed needs change to stop the current negative trend in Bitcoin. The FreeBSD project has a rigid internal hierarchy of people with write access to their codebase, which the various Bitcoin implementations also have, but BSD does this in a way that is very open to fresh eyes on their code, allowing parallel problem solving without the petty infighting we see in Bitcoin. Anyone can propose a commit publicly to the code, make it publicly available, and democratically decide which change ends up in the codebase. FreeBSD has a tiny number of core developers compared to the size of their codebase, but at any point, they have a huge community advancing their project without hard forks popping up at every small disagreement. Brian Armstrong commented recently on this flaw with Bitcoin development, particularly with the Core Devs:
“Being high IQ is not enough for a team to succeed. You need to make reasonable tradeoffs, collaborate, be welcoming, communicate, and be easy to work with. Any team that doesn’t have this will be unable to attract top talent and will struggle long term. In my opinion, perhaps the biggest risk in Bitcoin right now is, ironically, one of the things which has helped it the most in the past: the Bitcoin Core developers.”
FreeBSD Developer Heirarchy
This design environment drowns out financial and individual interest as the best solutions rise to the top of the heap for committing. It also attracts new talent, a problem lots of mature Open Source projects are faced with as a core team starts to define itself and becomes comfortable with their status.
The other thing Bitcoin devs could learn from is the BSD community’s adoption of the Unix Design philosophy. Primarily “Worse is Better,” The rule of Diversity, and Do One Thing and Do It Well. “Worse is Better” emphasizes using extant functional solutions rather than making more complex ones, even if they would be more robust. The Rule of Diversity stresses flexibility of the program being developed, allowing for modification and different implementations without breaking. Do one Thing and Do it well is a mantra of the BSD and Unix Communities that stresses modularity and progress over “perfect” solutions. Each of these elements help to make BSD a wildly successful open source project with a healthy development community and lots of inter-cooperation between the different BSD systems. While this is the opposite of what we see with Bitcoin at present, the situation is salvageable provided changes like this are made, especially by Core Developers.
The Change Bitcoin Needs is Already Out There
Prominent Figures in the Bitcoin community, like Gavin Andresen and Brian Armstrong, have been calling for changes that would fix the problems in Bitcoin in the long term. These structures have been in place for BSD developers for the same reasons we see problems with Bitcoin at present: Software development isn’t politics. You’re making a tangible change by working on your code, and outside interests should not be able to interfere with that process unless they are willing to commit fixes themselves.
For example, Apple uses BSD code heavily in Mac OSX. Say they wanted to start offering a server-specific spin of their platform. If they try to kneecap the coreBSD code downstream in any way to make their proprietary offering more attractive to the enterprise market, they’d have to get past thousands of code contributors who don’t share that sentiment, and no amount of smear or vitriol on social media could change that either. The current developers would have to embrace these changes, which isn’t likely, but the structures mentioned here would make Bitcoin’s development community resistant to the problems plaguing it right now. Furthermore, they already enjoy use in incredibly widespread OSS projects. Fixing Bitcoin isn’t impossible, and isn’t something we have to do post-cataclysmic implosion.
That’s why the deterministic view is dangerous; it expects failure for anything to change, where a few targeted, relatively simple changes could protect the developers from outside interests, at the same time encouraging new developers to help advance the project. Currently, Bitcoin is being designed by committee, with similar pomp and circumstance. This needs to change to enable long-term success, and the changes that would do this well are simple and have been tried and tested for more than three decades. I encourage anyone reading this to pressure devs to open up the code to contributors in a manner similar to BSD Projects. If the community can pressure them to the point of not developing their Specification, then surely it can pressure them to make some tweaks to their development methodology.
What changes would you like to see for Bitcoin development and Bitcoin in general? let us know in the comments!
Images courtesy of FreeBSD documentation
The post Bitcoin Devs Could Learn a Lot from BSD appeared first on Bitcoinist.net.
Bitcoin Devs Could Learn a Lot from BSD
No comments:
Post a Comment