Open Source Community Research

Written by Hunter Jansen on September 10, 2014

This semester at Seneca I’m enrolled in SPO600, and the first lab
assignment is to research two different open source communities with different licenses and review their practices and procedures
for discussing/accepting new code. This blog post covers those findings.

Docker

###What is it?
From their website - Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of
Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications
and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between
development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops,
data center VMs, and any cloud.

Docker is a well established project that has nearly 600 contributors, nearly 3000 forks, 75 releases and 10.5 thousand commits and is used by some large companies, as well
as individual developers as an alternative to workflows involving vagrant and virtualbox and the such.

###Community and Practices
Docker’s actually taken the liberty of writing up a rather descriptive series of processes you can follow for various forms of contribution.
You can find this doc on their github repo here. They use two main
forms of communication: Their mailing list for the discussion of
development plans and announcements, and using github issues to discuss and propose significant changes.

The contribution doc also outlines all the steps that are required for merge approval, patch conventions, code formatting, etc.

###A Successful Patch
I decided to follow a patch from it’s proposal stage here all the way through to its patched
implemenation here. I’ve looked through their mailing list, expecting to see a corresponding
conversation, but found none. This proposal itself has 50 people commenting on, however - looking through their other issues this is
outside the norm, and most issues range from 1-5 comments on them.

This particular proposal starts off with a suggestion for a feature, has some recommendations for additional functionality on that
feature, discussion of not only the original proposal but also the added on suggestions. Some discussion and questions on how
it would be implemented and how the community would prefer syntax/params to be defined. The original proposer is very active in the
conversation. Approximately two weeks after the original proposal and discussion a pull request from the original author is merged in
with starter code, requests for code review and people to help test.

As stated in their contribution guide, after a code maintainer uses LGTM (looks good to me) - the patch is merged into the release

Exercism.io

###What is it?
From their website - Application to support working through sequential programming problems, with crowd-sourced code reviews.

Exercism isn’t as well established as Docker, but has 200 contributors, 2 releases and 4020 commits

###Community and Practices
Exercism has also written up a contributing guide which can be found on their github repo here.
Pretty much all of their conversations happen on the issues pages for their github project. If a contributor is hoping to begin
work on a new language (as the project is essentially a code review platform), they need to email the main contributor to have the branch
created.

They follow github code formatting guidelines as well as a self written code of conduct. As well specific rules for successfully
working on a new language track.

###A Successful Patch
For Exercism I followed a merge request for a new feature here.
Looking at the messaging for this patch is fun, it involves a new contributor and an accidental merge! The new contributor is
helped out by a maintainer on the project, given tips on how best to submit their contribution. The patch is all but accepted, but then
there’s then a conversation regarding which CDN should be used if any, and which ruby gems to use. After some discussion
and guidance, the merge request is accidentally merged into master. After some more discussion, the merge is reverted and
ultimately the patch itself is put on the back burner until the project maintainer wants to put more time into it.

The whole mess is about 30 comments deep and is only contributed by three different parties.