Why are these important? Enterprises increasingly define software development as a top priority to gain competitive advantage or defend against disruption. They often turn to open source software because it is fast and agile. Enterprise IT decision makers should understand GitHub because it is the backbone of most open source projects.
Open source lets enterprises collaborate with all the other interested outside developers to create software that exceeds their internal capabilities. But it also means much of the collaboration takes place outside of the enterprise. Unsafe and disturbing it’s not because of controls, transparency and analytics.
Salted throughout the GitHub website are analytics, and there is an application programming interface (API) that data-driven enterprises can use to create their own analytics to measure the progress and health of any public open source projects important to them. A dashboard displaying the project’s heartbeat could be built with the API.
The majority of the project activity is commenting. It’s not too far removed from Facebook posts, except the comments are tersely written and often have code changes attached.
Think of GitHub as a crowdsourced public book editing system where an author submits a draft book to his or her editors and the public interested in the book. Editors and anyone interested can download a copy of the book. They can comment, rewrite or submit additional paragraphs pages and chapters. All of the changes can be sent back to the public book editing system or, using GitHub terminology, with a Pull Request.
A Pull Request means the proposed changes have been sent, the author and editors notified, but the changes have not been merged. The editors review all of the submitted changes, check them for proper spelling, grammar, and accuracy, and curate the best. The curated changes are merged with the original work into a final bestseller.
A translation of a recent event on one of the projects that GitHub reported about, Microsoft’s Roslyn project, is a useful introduction before turning to the data. GitHub usernames are used in this example.
This change to the project’s main body of code started last December when tmat suggesting a new feature in the Issues list. He might have written the software to implement the new feature to accompany his Issue—as GitHub contributors often do—but in this case, he didn’t.
After some clarifying revisions, user davkeen added tmat’s feature request to the priority backlog in February. Davkeen previously had been given the permissions by the project’s owner to accept issues into the backlog list.