Nick Heppleston, a fellow BizTalk blogger and user of my PipelineTesting library, left a comment on a recent post asking why I chose to put the library code on GitHub instead of CodePlex. I think it's a fair question, so let me provide some context.
As many of you are probably aware of it by now, there has been much talk lately about Distributed Version Control Systems (DVCS), as an alternative to the more traditional, centralized control systems that have been common in the past (and still are). DVCS has gained a lot of traction lately, particularly with Open Source projects because it really suits the already distributed nature of Open Source development.
For a long time I remained fairly skeptical of DVCS tools. To be honest, I just didn't get what the fuzz was about and centralized systems had worked just fine for me. I use CVS, Subversion and Team Foundation Server on a regular basis, and you can use all of them successfully with your projects. Obviously, each one has its strengths and issues, but they are all very usable tools.
However, during last year I've been working on a bunch of different projects where the workflow that suited my work style and my requirements best started to make using a centralized source control system a bit harder than it used to be before.
This made me realize that for some of the things I do, a centralized control system just doesn't cut it anymore. In other words, I crossed some invisible threshold where the SCCS stopped being an asset and started becoming a liability. Instead of having source control be a painless, frictionless process, it was becoming something I dread to deal with. And that's when I finally understood what DVCS was all about.
Why GIT?
So at that point I started to look into DVCS tools and playing a bit with them. There's a good discussion of some of the most important DVCS tools around, but in the end I finally settled for GIT, using the msysgit installation on my windows machines.
So far, I haven't really run into any really significant issues when running msysgit; the core stuff seems pretty solid, at least in my experience. I know there are some issues with git-svn in current builds, but I haven't used it yet so I can't comment on that.
I'm still very much a newbie at this, but I'm slowly getting the hang of it, and so far, I'm really liking it. Some aspects of git I really like are:
- Speed: It's pretty fast in most operations, even with large source code files (like tool-generated ones).
- Local branches: I love being able to create and switch between branches very easily and fast. Once you realize how easy it is to use them, you start taking advantage of branching a lot more than on regular, centralized version control systems.
- Single work-tree: Not having to maintain N-copies at the same time of your work directory when you're dealing with N-branches is a real plus in many cases. Of course, you can choose to do so if you like, but it's no necessary, like with other tools.
Why PipelineTesting?
I've always shared the code of my PipelineTesting library through this website. However, I was only publishing snapshots of the code, and while that was fine given how few people use it, it was sometimes a drag. I really did want to share the code more broadly and make it easier to get to some of the changes I was working on even when I had not explicitly released a new official version of the library.
Last year I even commented a bit on this topic and asked for feedback about what the best place to host the code for some of my projects might be, but in the end I didn't make any decision about it.
Why not CodePlex?
CodePlex is a fine site for publishing and hosting your open source projects. I was skeptical about it at first, but it really took off and has a number of things going for it.
The greatest strength that CodePlex has is precisely that it's a Microsoft-technology oriented site. This means that it is a natural choice both when publishing projects that explicitly target the MS stack, and when you're looking for open source projects based on said technology.
I think that, overall, the CodePlex team has done a great job of keeping the site running and making sure it became a viable and valuable service to the community (and Microsoft itself).
The downside of CodePlex is, unfortunately, the technology it is based on: Team Foundation System. TFS is a fine, robust, centralized source control tool. But it also has a few things that manage to take the fun out of using it:
- The support for working disconnected from the centralized server is just not good enough. Sure, it has improved a bit since the initial release, but it is far from a friction-less experience.
- The TFS Client, integrated into Visual Studio. This is supposed to be an asset, but, honestly, I don't always want my source control integrated into my IDE. It can be good sometimes, but it can also be very painful.
Just to set the record straight: Yes, I am aware of the command line tools for driving TFS, and that's certainly an option. Yes, I'm also aware of SvnBridge, which I haven't used myself yet, and it is a really good option and addition to CodePlex, but means running yet another tool.
Why GitHub?
The surest way to get proficient at something is to do it. I want to learn more about DVCS so that I can improve my workflow, and that means using my tool of choice.
For the time being, I'm choosing to stick with git for my personal projects (and some of my work). Given this choice, GitHub was a natural choice as to host my public stuff.
There are several aspects about GitHub that I like, but most of all, its that it is very simple overall, easy to get started with, and mostly stays out of my way. I also find the social aspects of it very intriguing, though naturally I'm not using those yet.
Of course, not everything is perfect in GitHub-land. Some will argue that it doesn't offer as many features as CodePlex in some aspects (like no forums) but that doesn't bother me at this point, as I don't really need that for now.
A bigger issue, however, could be that GitHub is not yet a very visible site among the .NET/BizTalk communities. Heck, I'm pretty sure PipelineTesting is the only BizTalk-related project on it :-). I think that anyone looking for my library is probably going to find it through this weblog first, so I'm not that worried about it, and the BizTalk community itself isn't all that large (it has grown enormously, but it's still small by comparison).
What's next?
I plan to contin
ue working on PipelineTesting and I have a few features in mind for the next release. If anyone wants to contribute or has suggestions/bugs, please let me know about it!
I will continue to offer a copy of the library for download that includes a snapshot of the source code and a pre-compiled copy of the library, like I've been doing so far. People shouldn't have to install git just to get a copy of the library and use it, unless they need something in the code that's not yet in an "official" build. Of course, I'm a nice guy, so if you really really need it, just ask :-).
I also plan to start taking advantage of some GitHub features. In particular, I want to migrate some of the "documentation" that I've written over time as blog posts to a more appropriate format that's easier to maintain and to use. For this, I want to put the GitHub Wiki to use and also add a proper readme file to make it easier to get started with the library.
