We're happy to say that we recently released the code for the TraceView Ruby instrumentation on Github as Open Source. There are a ton of benefits for AppNeta (and the community) in doing this so making the decision was easy... but the process of actually opening the repository and still keeping a few things private was slightly trickier. Here's the route we took that has worked out really well.
The Ruby instrumentation has always been sheltered on Github - albeit always in a private Github repository. We used the issues, pull requests and wiki pages extensively for everything from new employee resources to hosting screenshots, customer issues, internal discussions and links to other project and management tools (e.g. Asana).
Outside of the commits and the code, everything else was either of little use to the public or potentially company or customer confidential - stuff that shouldn't or couldn't be shared publicly. So this put us in a quandry: How do we open our private repository but strip all of the unnecessary cruft?
After some thought and discussion, we decided to go the route of using two separate repositories entirely: the original private repository and duplicate open repository.
The existing private repository is used for:
- internal discussions, debates and research
- handling of potentially private customer issues
- anything else that wasn't appropriate for public consumption
..and the duplicated public repository is used for:
- hosting upcoming releases
- public facing issues - contributed by the community and/or our development or support team
- accept public pull requests and improvements
- everything else
In terms of git commits, the two repositories are duplicates of each other. They are kept in sync by pushing and pulling commits back and forth between the two.
Next, I'll explain the exact steps we took to set this up.
To setup the new public repository, we first created a new open empty repository in our AppNeta account. We then followed the steps in this Github support article which duplicated all of the commits from the private repository to the new repository.
This gave us a second open repository that is identical in terms of code and commit history but without any of the issues, pull requests and wiki.
To work with this second repository locally, we add another git remote to our local clone:
git remote add public git@github.com:appneta/oboe-ruby.git
The remotes then look similar to something like this:
With this second remote added, we can now do things like fetching commits from the public repo and apply them to the private repository. Commits are atomic and once exist in one repository, are trivial to apply to the other.
For example, if we wanted to retrieve commits from the public repo and push them to the private repository we would run:
git fetch public
git merge public/master
git push origin master
and for tags:
git fetch public --tags
git push origin --tags
It's important to have a good understanding of the differences between git pull and git fetch. See Github's What is the difference between fetch and pull? article.
With this ability to push and pull commits easily between repositories, the existing workflows don't need to change much (or at all). As for AppNeta's Ruby release process, we merge all proposed commits into a "release candidate" branch, create a pull request and begin the full testing and release process from there.
This can be done on either repository but since we are dedicated to having an open development process, going-forward, we do this in the public repo. appneta/oboe-ruby#2 was our first release from the public repo! Who knows, maybe eventually we can rid ourselves of the private repository entirely.
This process allows for us to develop publicly, accept community commits and release in the open fairly trivially.
From here, we've begun migrating over the existing issues from our private repository and newly identified issues we add to the public repository by default.
And now that the repository is in the open, we can use all the slick tools like Travis CI, Code Climate and GemFury.
For those with existing private Github repositories with a fair amount of history, going open source can raise a lot of questions such as:
- Will going Open Source breech any existing customer confidentiality agreements?
- Are links to company internal resources and tools useful publicly?
- Is there any company proprietary information in the private repository?
- Are there any historical 'less than savory' comments, discussions or links in the private repository?
Using two separate repositories alleviates most of the risk associated with the questions above. It allows for you to release your code first (and fully) and then hand pick other pertinent items to expose publicly - a much needed "soft-step" in to the Open Source world for those with large repositories with considerable history.
Who knows? After a while of using this setup, maybe the next thing you'll be researching, is how to delete your private repository entirely. It's already crossed my mind. Viva la Open Source!
- TraceView and Ruby: Now Open Source!
- How to Configure Remotes
- What is the difference between fetch and pull?
- Duplicating a Repository (used to clone the commits from the private repo to the public repo)