Interactive charts

Link to Figure (Copy)

[ View interactive graphic fullscreen ]

Repositories reveal interesting trends about organizations

The core code supporting Bitcoin was published in April 2009. Since then, the number of projects on GitHub related to blockchain has grown significantly, averaging more than 8,600 new projects a year. In 2016 alone, there were almost 27,000 new projects (figure 3).

The growth in the number of projects has been matched by the rapid growth of content produced to develop these blockchain technologies. Please see figure 4, and Repositories by year in our interactive dashboard.

In analyzing blockchain repositories and their content, we noticed that increasingly more organizations appear to be getting involved. In 2010, organizations developed less than 1 percent of all projects. By 2017, their blockchain projects accounted for 11 percent (organizations currently account for 7 percent of total—not just blockchain—software development on GitHub). And recent data about the rate at which commercial organizations can find success with blockchain initiatives through open source seems promising; some high-profile, large commercial entities are already doing so. (Please refer to Repositories by organization in our interactive dashboard.)

Of particular significance, some projects that organizations have developed have resulted in new platforms (such as Ethereum, Ripple, Corda, and Quorum) which some developers now use to build applications. Organization-owned projects also tend to be updated more frequently than those developed by users, and are reportedly five times more likely to be copied, implying that the blockchain community has deemed them most relevant.

When a project is copied, all of the content becomes available to the account that copied the project, thus working as a de facto knowledge-transfer mechanism. This process is commonly referred to as a citation network (see Appendix for network definitions),¹¹ where projects that are most often copied occupy a more central role in the network of projects, which we refer to as project centrality. Under this rubric, some of the most central projects have been developed and maintained by organizations: Bitcoin core, the C++ and Go implementation of Ethereum, Python clients for Ethereum, and the Bitcoin Improvements Proposal. To interactively explore a depiction of the various networks in GitHub, please see Network visualization in our interactive dashboard.

When exploring the aforementioned interactive graph, keep in mind that the initial projects of Ethereum and Bitcoin are maintained by organizations (foundations), and that a vast amount of blockchain projects and applications in GitHub are actually built on top of these two projects. In short, organization-led projects are the backbone code for thousands of other projects. Out of the 20 most central projects in the blockchain space measured by popularity, citation, and collaboration (see Appendix for network definitions), 18 were created and maintained by organizations (see table 1).

Organizational commitment in open source appears to be dominating the core development of blockchain because it is most likely more demanding and purposeful than individual participation in development. Once resources are put into place by an organization, there is generally more incentive to ensure that the project is successful. Given that organization participants are tied to one another beyond any particular project, there is often greater accountability to one another, which also drives ongoing development.

Blockchain evolution is largely about the “community”

A community on open source is a group of developers with shared interests that develops and improves existing content. We identified 772 different blockchain communities on GitHub. Each community is typically defined by patterns of collaboration between these projects that can give rise to new applications. For example, the Ethereum platform was initially developed by two central figures in the Bitcoin project; their project has since evolved into the largest blockchain community, measured by active projects, on GitHub (see the sidebar, “Understanding the Ethereum ecosystem”).

In the blockchain space, communities of projects comprise at least 25 projects, with some large clusters including hundreds of projects (see Communities of repositories in our interactive dashboard).

By studying communities, we can explore how projects that have developed a specialization enable the creation of new applications. For example, we found that tools for enabling crowdsales and initial coin offerings (ICOs) are often connected to projects in large blockchain subcommunities: projects developing content for smart contracts, escrow accounts, and the core code behind Ethereum in the Go language. Not surprisingly, this seems to align with the predilection of many ICOs being offered on top of the Ethereum blockchain (for more information on ICOs, please read “Initial coin offering: A new paradigm,” Deloitte¹²). Ethereum allows developers and start-ups to issue their own currency, including in the form of an ICO, on the Etherum blockchain through smart contracts, which can seriously reduce the token and cryptocurrency barrier to entry.¹³

An interesting example of how seemingly disparate communities connect is the Monero cryptocurrency, created in 2014. Monero has concertedly different attributes than Bitcoin regarding its level of privacy (no reuse of addresses allowed), scalability (no blocksize limit), and security (more forced decentralization).¹⁴ Still, the community that contains Monero and related projects has a strong connection to the community that contains the main Bitcoin repository.

It could potentially be especially important for blockchain developers to pay close attention to communities. Our analysis reveals that many projects that specialize in particular industries or types of applications in the blockchain space that are enriching the ecosystem have strong community affiliations.

Interpreting the mortality rate of blockchain projects

The stark reality of open-source projects is that most are abandoned or do not achieve meaningful scale. Unfortunately, blockchain is not immune to this reality. Our analysis found that only 8 percent of projects are active, which we define as being updated at least once in the last six months. Here, organizations are a positive differentiator; while 7 percent of projects developed by users are active, 15 percent of projects developed by organizations are active.

The mortality rate of projects is often an essential factor in understanding project centrality and the emergence of protocols and best practices. For commercial purposes, since few projects will likely survive, understanding the factors that contribute to a project’s mortality may be an essential skill for firms wishing to piggyback on a successful code, emulate successful projects, or build in-house capabilities.¹⁵ Note that about 90 percent of projects developed on GitHub become idle, and the average life span of a project is about one year, with the highest mortality rate occurring within the first six months. Our analysis revealed 11 variables associated to a project becoming inactive. Of these variables, organizations should consider the following three in particular:

• First, perhaps not surprisingly, projects developed by users tend to have shorter life spans and to be stand-alone blockchain technology applications rather than foundational libraries that enable the creation of multiple applications. We found that users were more prone to tinker, developing and prototyping ideas that often do not gain traction.
• Second, is the concentration of contributions to a project. Our analysis indicates that most projects with high mortality rates are those in which one committer generated the vast majority of content, and, in fact, the median project (measured by number of committers) has only one committer (see Glossary in Appendix for definitions of types of repository participants). Often this sole, or lead, developer shifts attention to other projects or simply becomes disengaged. On the other hand, most projects that survive tend to have multiple committers with less concentration of activity attributed to one particular committer. Predictably, most organizations are structured in this latter manner.
• Third, projects with higher numbers of copies (forks) of a project are more prone to survive while those with few or no copies are more prone to stall as will their copies. In fact, regarding the latter, a copy of a project also tends to have less committers and hence higher mortality rates. This is not to say that there are not highly successful projects that are the products of forks, but generally projects that are forks of projects tend to have high mortality rates due to a paucity of new committers.

Programming languages lean toward financial services

For potential developers, the question that often surfaces first is, “How should we start?” To help answer that question, it can be important to find out what’s under the hood of existing projects. Although not the most popular language when measured by number of blockchain repositories, we found that C++ was used most in the ecosystems’ central repositories. This was not surprising, given that C++ has been used for some time in the financial services industry to develop applications that demand efficient memory management, speed, and reliability. For the heavy lifting behind cryptocurrency projects (Bitcoin included), C++ is still the favored language. And for the most central repositories on GitHub, C++ accounts for almost one-half of all the content (see Most popular languages in our interactive dashboard.).

However, we also discovered that Go, the programming language developed by Google in 2009, appears to be gaining traction. It is now the second largest language used for blockchain-related projects. Go seems to have rapidly evolved from a fringe language to one of the centerpieces of the GitHub blockchain ecosystem. Just two years ago, in 2015, less than 2 percent of all of the content of projects in the blockchain space were developed in Go. Programmers attribute the meteoric rise of Go to its simplicity and ability to scale.¹⁶ And while financial services firms do reportedly rely on the memory management, speed, and reliability of C++, scalability appears to also be an exceptionally high priority for financial services firms that interact and transact with multiple and diffuse stakeholders. It also seems telling that Ethereum and Hyperledger projects, which both involve integrating other technologies into blockchain to expand its use beyond cryptocurrencies, reportedly favor Go.

Identifying blockchain talent by geography

Given that an important issue that financial institutions face is hiring the necessary talent to develop, implement, or maintain new technologies, we thought it would be helpful to know where top blockchain talent contributing to GitHub resides. Most GitHub project owners—developers who start repositories—live in North America or Europe, with San Francisco having the largest concentration. Interestingly, the next two most popular cities to find project owners are two traditional financial services hubs: London and New York. (See figure 5 and Repositories by geography in our interactive dashboard.)

We found that projects coming from San Francisco are diverse; they include solutions for exchanges, wallets for cryptocurrencies, interfaces for different blockchains (for example, Ripple, Hyperledger, and Ethereum), and payment tools for cryptocurrencies, to name a few. The ecosystem in London is also varied, but features more projects connected to the Ethereum community, which would also imply more projects around accompanying technologies, such as digital identities, smart contracts, and open APIs. Participants in New York appear to be specializing in projects that are geared toward traditional financial services. It is also worth noting the high level of activity in China, specifically, Shanghai and Beijing. In both of these cities, most of the projects pertain to cryptocurrencies and cryptocurrency exchanges, with an emphasis on scalability.

How could financial services use the GitHub analysis?

The data scientists of Deloitte developed and honed a methodology to analyze and organize GitHub data in order to better understand the evolution of a young, possibly transformative technology and its ecosystem. Our overall objective is to provide insights that help financial institutions make better, more informed decisions and avoid pitfalls.

From this effort, we have learned that financial services firms are involved in blockchain development on GitHub. There are essentially two types of participators on GitHub: the committer and the watcher. The committer makes commits, or contributions to code, while the watcher follows the development of a project without making code contributions. So far, few financial services firms’ employees are committers to projects on the firms’ behalf. There are, however, a few high-profile financial services firms that not only commit, but actually have their own projects running under their brand with significant commits.

Nonetheless, financial services firms seem predominantly engaged as watchers of projects in GitHub. It is difficult to get an actual number on these watchers as they can be watching under handles or private email addresses. Regardless, our analysis can equip both financial services committers and watchers with perhaps a unique opportunity to gain access to a large and nuanced view of the blockchain ecosystem. Leveraging our analytical methodology, firms can now target multiple projects for possible involvement or learning, identify talent using a variety of metrics, see how changes in protocol and trends can point toward standardization and interoperability, and, finally, all of this and more can increase their understanding of blockchain’s evolution.

Specifically, our analysis may enable financial institutions, and other firms, to:

• Identify pockets of opportunities for future innovation—where to invest, how much, and when
• Determine where competitors are playing already and identify gaps
• Understand and predict which languages are gaining/losing ground using which types of applications, and invest accordingly
• Determine where talent and expertise exist and how best to leverage the geographic distribution of talent
• Assess partnerships and collaboration opportunities

It is our hope that these findings can arm the financial services industry with the data it may need to not only better identify successful projects and opportunities based on how the blockchain ecosystem is evolving, but to become influential participants, themselves, in how blockchain evolves.

Appendix

Network analysis

We use several metrics commonly used in the field of network analysis, such as number of connections (degree), centrality (PageRank score), and clustering (community detection).²¹ We defined three types of network connections in our analysis:

Collaboration measures the contribution of projects to each other. To build this network, we identified the repositories that received collaborations from each other in our universe of blockchain projects rather than the entire GitHub set.

Citation measures the use of a project’s content by another project. Projects that are highly cited tend to have a high centrality score (see the next section). To build the network, we identified users who copied a repository, joining his or her projects with the project that he or she copied.

Followers measures the popularity of a project within other projects. To build the network, we identified users who followed a given repository in our universe and joined these users’ projects.

Centrality analysis

To identify the most central repositories in our network, we used the PageRank (PR) score. Developed by Google, PageRank is a common metric to identify centrality in a network and has been widely used in several fields. We calculated the PR score for each of our three networks.²² Once we obtained the PR score, we ranked the projects based on the value of that metric. We repeated the process for the three networks and created a composite score defined accordingly:

Centrality Score values that are closer to 1 indicate a more central role in the network.

Identifying communities

To identify communities in our network, we implemented a commonly used community detection algorithm for large graphs known as fast greedy community detection algorithm.²³ The algorithm iterates through the different network connections, adding projects to a community until a local optimal value is reached. The algorithm repeats this process until there are no further improvements. We implemented the algorithm in the collaboration network.

Project mortality

To identify factors associated to a project becoming inactive, we implemented two classification models: a logistic regression and a random forest.²⁴ The logistic regression was used to identify meaningful variables while the random forest is used to identify which projects become idle.