This is the first article in which I am going to introduce some interesting things we can find out while reviewing open source code repository hosted on the most popular platform for such projects - GitHub.

Introduction

Nowadays, the are many interesting sources which will help you to get to know about current state of the blockchain based project:

• blogs and posts on steemit and other platforms;
• web pages, web magazines and a lot of articles on the Internet;
• podcasts, videoblogs, YouTube channels etc.

Most of them are pretty interesting and definietly has some value, but unfortunately plenty of those are maintained by non-techy people who are aggregating informations from other sources, rewrite them and presenting in more fancy way.

In the crypto world we should mainly focus on the technology side of the project (at least at early stage) and one of the best way to do it is to look into GitHub repository of the specific project. It is commonly known that one the biggest advantage of the most crypto / blockchain project is ability to view the source code (it is also good way to recognize scam, if the code repository of the project is not open source or is very poor this is probably a scam, fake project focused on taking as much money from you as it is possible).

Lets see what we can read from the open sourced repository. Below I will analyze Lisk project. The are many rumors about it and a lot of discussions online, but what are the development facts which we can gather during the little research on the project repository? My interpretation below.

GDA (GitHub Deep Analytics) - Lisk

During this article we will aggregate data from whole GitHub organization - LiskHQ. I believe that this good approach because usually project is maintained by contributors from organization and if we are trying to determine the current state of the whole project - we have to look at every single subproject of it. For the Lisk we have 6 repositories:

• lisk - Lisk blockchain application platform;
• lisk-hub - Graphical User Interface (GUI) to manage Lisk IDs, tokens and your sidechains;
• lisk-template - Template repository for Lisk projects;
• lisk-commander - A command line interface for Lisk;
• lisk elements - JavaScript library for sending Lisk transactions from the client or server;
• lisk-explorer - Lisk blockchain explorer.

Of course some of them are less important some more, but they all have to work well and have great support if project is going to succeed.

Time Frame - 01-31.05.2018

All data, diagrams, tables and so are from May 2018.

Repositories

Terms used here:

• Coding Hours - estimated time spent on development;
• Coding Volume - estimated code volume;
• Productive Code - code that is not rewritten soon;
• Efficiency - ratio of productive code to all code;
• Velocity - ratio of productive code volume to coding hours.

The numbers on the top refer to the analyzed time period. The numbers on the bottom show comparisions to the previous period.

There are two interesting things here:

• increased efficiency of the main project - lisk (Lisk blockchain application platform) and less time spent on it. It might mean that the team is more experienced and focused on specific, better defined tasks;
• decreased efficiency of the - lisk commander (allows you to communicate with a remote or local node and carry out Lisk-related functionality) and more time spent on it. It might mean that this part of the project will have some big changes in the release and probably some previoulsy assumptions were changed.

On the above chart we can see that most of their time, developers were spending on the lisk-hub project.

Productive vs. unproductive work

Terms used here:

• productive work - the number of lines that are not unproductive (above);
• unproductive work - is the number of lines that has been changed shortly after it was created (below).

Pull Requests and Issues

Terms used here:

• Pull Request - A pull request is a method of submitting contributions to project;
• Issue - Issues can act as more than just a place to report software bugs, we can use Issues to organize tasks you'd like to accomplish, such as adding new features or auditing old ones.

In the ideal scenario the number of the Issues and Pull Requests should equal it would mean that each Issue is resolved by each separate Pull Request. In my opinion when project is well maintained these numbers strive for equalization. When the number of Issues is greater then number of Pull Request it might mean that project is still in early development phase.

Above table presents how long some of the Issues and Pull Requests are open.

Some explanation for the above table. We can see there how many Issues are reported for each project, the interesting part of this table is column - Assignees which means how many of these Issues has a developer who is responsible for resolving and/or fixing it. Probably if the Issue do not have developer assigned to it, it won't be fixed in the nearest development cycle.

How long it usually take to resolve the Issue for development team? The following chart shows the value of the median.

It is good that this time is decreasing, it might mean that developers are cooperating more efficiency during the development, the project is more solid and better maintained in time.

Summary

It was quite long post, hope you enjoyed it. I tried to interpret the data as little as possible to also give you the ability to do it with your own. I think that this kind of report will help you the make some good insights abut this specific blockchain based project - Lisk. Please let me know if it is interesting for you and if yes in which cryptocurrency project are you willing to read next.