Companies and open-source software projects alike have CEO, lead developers, or other forms of leadership. And that leadership exists not just to provide a face for the, but to make tough, even controversial decisions when needed.
Apple has a long history of introducing controversial, disruptive changes to its business and plowing forward, from its long ago decision to abandon the Apple II product line (then, it’s cash cow) in favor of pursuing the Macintosh, to transitioning macs from using the Motorolla 68k series of processors to PowerPC chips, soliciting and gaining investment from their arch-Rival Microsoft, moving from the old-style MacOS to the incompatible Unix-based MacOS X, transitioning processors (again) from PowerPC to the Intel x86 family. Even “little” changes brought out the protesters, such as abandoning SCSI, ADB and serial port connectivity for the new-fangled USB; refusing to support Flash in iOS; dropping floppy drives; dripping CD and DVD drives. Each of these decisions (made by a variety of CEO’s, but mostly Steve Jobs) were controversial at the time, bringing out varying amounts of protest from users and developers alike.
Apples not unique; IBM’s decision to jettison its PC business to Lenovo is another big, almost company changing decision made by its executives.
Everywhere you look, you see that successful companies have leaders who are are able to push forward through controversial decisions.
(adsbygoogle = window.adsbygoogle || ).push();
That gets translated to the opensource world as well; while anyone can submit code and patches for the Linux kernel, woe to anyone who submits code that’s not to Linus Torvalds’ liking. Ultimately, Linux (the kernel) is his baby; people can fork it if they’d like, but no one can dictate what Linux is or where it’s going but Linus himself.
Theo De Raadt is a similar personality occupying the helm of OpenBSD. In fact, due to disagreement with the direction NetBSD was taking, De Raadt forked the project to create OpenBSD. More recently, in the face of Heartbleed vulnerabilities found in OpenSSL, De Raadt opted to fork that code as well, in order to create LibreSSL
And MySQL creator Michael Widenius had long taken a hands off approach to his baby, only to see Oracle consume and neglect it; in reaction, he returned, forked the code base and created MariaDB.
Now, take Bitcoin. When he introduced it to the world, Bitcoin was undeniably Satoshi’s baby. People helped, people contributed, but ultimately, everyone knew it was Satoshi’s baby and he was the final arbiter of where Bitcoin would go and how it would get there. From my understanding of the events (this all happened before I became very interested in Bitcoin), before disappearing from the scene, Satoshi effectively handed the reigns over to Gavin to continue on in his stead. Unfortunately for Gavin, (and for the community, IMO), not being Bitcoin’s creator, Gavin hasn’t been able to muster anywhere near the support as Satoshi had. He never trully became the leader or the final arbiter, only its chief evangelist.
Where am I going with this?
The block size debate, of course.
(adsbygoogle = window.adsbygoogle || ).push();
The longer this goes on, the more Bitcoin’s credibility suffers. No matter what the outcome is, what we’re seeing is the weakness of this leadership by “committee” that Bitcoin has become. When the tasks laid out are simple, non-controvertial, such as bug fixes, improving performance for tasks such as the time it takes a new node to download the blockchain, no problems, the committee style works. But when changes involve anything the least bit contentious (to use the word of the week
I feel it’s reaching a maddening point. We’re at a point where nearly everyone acknowledges that the block size is not sufficient for future growth.
There’s one camp that is insistent on fixing it before it becomes an issue, and have put forward a solution that, given sufficient time for the code changes to propogate to nodes and miners, and for 3rd party developers to update their software, would cause minimal disruption.
There’s another camp that sees that there’s a future problem, but since it’s not affecting anything today, wants to put off future changes.
Yet another camp sees the problem, but feels that increasing the block size isn’t the solution at all, preferring to look for new layers (such as side chains and the Lightning Network) of increased complexity to lay on top of the protocol rather than fixing the protocol itself.
And during all this infighting, people hope that more people adopt Bitcoin, and for more companies attempt to integrate the blockchain into their workflows as NASDAQ Private Markets and the nation of Honduras are doing. I can’t help but think that there is some serious rethinking of that strategy going on right now, by companies that have already announced such initiatives and by companies considering such initiatives alike.
And the real kicker is, were Satoshi around, this debate would never have occurred. Bitcoin was his baby, everyone knew it and acknowledged it. Passing the torch to Gavin, symbolic gesture that it was, was only that. A gesture that clearly no one took to heart.
Bitcoin needs leadership now more than ever, but after being leaderless for all these years, it’s clear that no one is willing to accept anyone at the helm. Which will likely turn out to be to everyones detriment.
Bitcoin.org Hard Fork Policy – https://bitcoin.org/en/posts/hard-fork-policy
A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes – http://flosshub.org/sites/flosshub.org/files/paper_0.pdf
Apple’s Transition to Intel Processors – https://en.wikipedia.org/wiki/Apple’s_transition_to_Intel_processors
Forking MySQL/ for how long can forks keep up? – http://datacharmer.blogspot.com/2013/09/forking-mysql-for-how-long-can-forks.html
“The Bitcoin Lightning Network” paper, version 0.5 – http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
OpenBSD forks, prunes, fixes OpenSSLOpenBSD forks, prunes, fixes OpenSSL – http://www.zdnet.com/article/openbsd-forks-prunes-fixes-openssl/