What I've learned about open source by pairing with Simon Cropp

Over the last 2 weeks I have be fortunate enough to pair with Simon Cropp for about 8 hours on my open source project ApprovalTests.  Simon has taught me a lot about running a better open source project, this blog is an attempt to share some of that for those not fortunate enough to be able to pair with Simon themselves.

Think about your 'brand'

Often I am writing ApprovalTests because I use ApprovalTests myself. I am happy that others find it useful as well and believe in sharing and open source, so I also make it an open source project. However, all of my thinking goes into after a programmer has it on their computer. However, there is a lot of things that happen before someone has ApprovalTests on their computer. Most of what I am about to talk about is specific to this area of open source. In the 8 hours we paired, we spent surprising little time actually programming C#.

It works on my computer

I believe this is particularly harder with .Net than other languages. There were many things that I just assumed everyone had because I never thought I did a special installed for them. Some of these were libraries that were put in my Global Assembly Cache (GAC)  by VisualStudio (2010) but not by (2012). That means adding .dll's which means configuring git.

Git and binary files

I really wish then was a simple header to all files indicating that they are a binary or text file. There isn't. This becomes an issue with git, so if you are checking in binary files, you need to set your .gitattributes to include them. For example,  I added the following to my .gitattributes:

#Binary

*.dll  binary

*.exe  binary

*.png  binary

*.tif  binary

*.tiff binary

*.snk  binary

*.ttf  binary

If you don't do this as soon as someone clones your repo, there will already be changes.

Removing Cruft 

I'm pretty good about cleaning my code, but what about my project in general? All though references you don't use anymore? That Silverlight experiment? Even dll's that are in your project but no longer referenced by your project. All of that makes it harder for someone else to clone and play with your source.

Consistency

This project started before nuget, so there were dll's that were added directly that now should be added by nuget. It's hard to remember the advantage of consistency in a project, especially as it is not bothering you. This is a double edged sword with pairing. On the one hand it's easy to code because you have your environment setup plus already know the tricks. On the other hand, it masks trouble that a lone programmer will have with your source.

Version Numbers and Signed Code

This is a long post, but the short version is that in the end I followed JSON.net's model for version numbers. This means that while the nuget version number will increase, the version number for ApprovalTests will now remain at 1.22 for all time. Because I sign ApprovalTests, this allows me better compatibility with other software.

Version Numbers & Simple Builds

An other problem was getting a single place for the version numbers. This required a bit of awesome hacking on Simon's part.  Here's the high level view

1. create a solution level file for the version number
2. add it to packages via link (there is a drop down on add)
   
3. Manually change your .csproj file to move it into your properties folder
   Properties\VersionInfo.cs
4. Use this when creating your nuget with the -Version flag

If any of this was confusing checkout these files from my project: VersionInfo.cs , ApprovalTests.csproj, ApprovalTests.CSharp.nuspec, CreateNuget.cmd

1 .dll per Nuget

Having more than one dll file in a nuget package is a bit counter productive since you now can't use only 1 of them. In my case I had 2, so now I have two nuget packages: ApprovalTests & ApprovalUtilities. Of course, ApprovalTest depends on ApprovalUtilities, but you can now use the Utilities on it's own, as originally intended.

Think long term

On the Internet things live forever. Whenever possible link to a domain you control that can move with you. When I started everything was on sourceforge, now I have moved to github and links I have posted will be broken because of that. That history that creeps into your project isn't just in you code. Your brand is the full experience. Blogs, videos, stackoverflow questions, packages, repos, code, api's. Try to make it still work 5 years from now.

More to come...

This blog is already getting pretty long, and there is still much more Simon as got me thinking about. Here's my current todo list:

1. Continuous Integration Server - I'm a big believer in this on regular projects but it seemed like overkill when I was the only committer. I just had to remember to always run my tests. But there is an other advantage here. I keeps me aware of at least 2 machines, meaning it will be easier to think of other people who clone the repo.
2. Website - On top of moving the website to github, and using a static website generator like jekyll. I am also aware of needing to structure my website to guide people to Understanding the Code, Using the Code, and Browsing the Code. A very nice example of this in the NancyFx Page.
3. Documentation - This includes what goes in the blog vs into a wiki. The main difference being that wiki should be relevant next year, while a blog is relevant NOW and not so important next year.

Again, a super big thanks for all the help Simon has given me. I have paired with more than 50 people across the globe and all of them have been very helpful to me. Simon had a particular gift for understanding the branding of an open source project and was very patience working with me to improve ApprovalTests.