Bitcoin Developers Take No Holidays
Nobody controls Bitcoin. Nobody owns its code, and no one knows how to turn the network off. As Bitcoin consists mostly of software, its future is largely decided by its community of volunteer developers. And these developers, the accompanying chart shows, are a passionate group who rarely take a break. With the exception of possibly Easter, during which activity visibly decreased, Bitcoin development does not slow down on weekends or holidays.
Bitcoin's most popular implementation, Bitcoin Core, is run by approximately 95% of all nodes. Its contributors largely gather around mailing lists, slack channels and of course the Github coding platform, recently bought by Microsoft, where 547 contributors have been listed since 2009, and 54 over the past year alone.
Over the past three and half years, Github data shows, Bitcoin Core developers have worked relentlessly to resolve issues. One notable exception seems to be December 2015, presumably because many developers took the time to travel to the Scaling Bitcoin conference in Hong Kong to debate solutions to Bitcoin’s capacity limits. Then, Bitcoin Core developer Pieter Wuille presented the concept of Segregated Witness (Segwit), which was activated two years later.
Anybody can read Bitcoin’s code and its proposed changes, and anybody can propose their own changes by "forking"’ the code and proposing a "merge" of other contributions with a so-called “pull request." (Please see below for a glossary of Github terms). Such forks are not necessarily the much-feared forks of the Bitcoin network.
The majority of code, for example relating to how to calculate fees, is not relevant for Bitcoin's consensus mechanism, which relates to code that governs what constitutes a valid block on the Bitcoin blockchain. The rule that a block can only be of 1MB in size (excluding some signatures) is probably the most famous and contentious consensus-relevant code. But this controversy, important as it is, does not occupy the bulk of developers' time.
Developers worked to merge pull requests and released a new version of what is essentially Bitcoin’s reference client. The main following of the Bitcoin Github repository, as defined by people watching or forking the code, unsurprisingly also correlates with the Bitcoin price, which reached new all-time highs around December of 2017 and January of 2018. There are now almost 20,000 forks of the Bitcoin code, with 3,300 people enabling notifications.
Releases are coming out regularly and are generally - and with the exception of 0.15.0 in September 2017 --- are bug free.
While the number of contributors to the project is on the rise, the data also shows there have been no changes in the administration team of the Bitcoin repository. No members were added or removed in the past 18 months. Interestingly, forks and watch events are cyclical, but merges, pulls and issues are not.
A dedicated and motivated developer community is crucial to the success of Bitcoin. There is plenty of work to be done, demontrated by complications around "fee events," during which transaction fees spike.
There are other challenges on the horizon. Recently, multiple developers have expressed their discontent with Microsoft’s acquisition of the Github platform. Wladimir van der Laan, the current maintainer of the repository, hinted in a tweet the project might be moving to the open-source alternative GitLab. Bitcoin development will undoubtedly continue, but where that development will take place is not yet determined. Most likely, it will be on a self-hosted server, multiplied all over the web -- truly in the spirit of Bitcoin’s decentralization.
Leo Weese is president of the Bitcoin Association of Hong Kong.
A Brief Glossary of Github Terms:
Commit Comment Event: triggered when a commit comment is created.
Create Event: represents a created repository, branch or tag.
Delete Event: represents a deleted branch or tag.
Fork Event: triggered when a user forks a repository.
Gollum Event: triggered when a Wiki page is created or updated.
Issue Comment Event: triggered when an issue comment is created, edited, or deleted.
Issue Event: triggered when an issue is assigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, or reopened.
Member Event: Triggered when a user is added or removed as a collaborator to a repository, or has their permissions changed.
Pull Request Event: Triggered when a pull request is assigned, unassigned, labeled, unlabeled, opened, edited, closed, reopened, or synchronized. Also triggered when a pull request review is requested, or when a review request is removed.
Pull Request Review Comment Event: triggered when a comment on a pull request's unified diff is created, edited, or deleted.
Push Event: triggered on a push (commit) to a repository branch. Branch pushes and repository tag pushes also trigger push events.
Release Event: triggered when a release is published.
Watch Event: is related to starring a repository, not watching.