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.
Both of these projects can be found on github!
###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.
###Licensing Docker is licensed under the Apache License, Version 2.0
###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
###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
###Licensing Exercism is licensed under the GNU Affero General Public License
###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.
So while it’s not exactly, SUCCESSFUL, it DID get merged into master!
###That’s it! Until Next time -Hunter