Iterated Dynamics Moved From SourceForge To CodePlex

Over the past few years, I’ve become increasingly disappointed with SourceForge for my open source projects. It used to be the first place I would suggest for hosting open source projects; now I would never recommend it. As a result, I’ve moved Iterated Dynamics to CodePlex.

So why did I move? A number of things have caused me to switch. First, SourceForge has been getting slower and more difficult to navigate as time moves on. They have changed their page design a number of times and each time it seemed to me that usability has suffered. The pages on CodePlex seem to load significantly faster than the pages on sourceforge and are easy to navigate. I never did anything fancy with my sourceforge projects, I simply wanted a place to host the source code, provide a bug tracker and maybe a discussion area. My open source projects are fairly niche affairs and have generally consisted of myself as the only developer. So the usability of sourceforge was an important factor in deciding where I should host my open source projects.

Then there were the bugs. As SourceForge would tinker around with their project page templates and web site design, there was more than one occasion when the links to my project broke or simply disappeared. One could consider a disconnect between the SourceForge staff and their customers to also be a bug. Its difficult to find the right place in sourceforge where you can talk about sourceforge itself. While you can eventually find it, its another usability problem that it takes diligent searching to find the forum where you’re supposed to contribute to making sourceforge better. When I did eventually find the forum, I asked what SourceForge was doing in its roadmap to support agile collaborative development for projects. Was there any plan on integrating the idea of user stories, continuous integration, unit testing and so-on? The responses seemed to indicate that they hadn’t a clue what this “agile development” thing was, even though I’d been doing it for a decade at that point. They seemed to think I wanted a build server and opined that their build server experiments indicated that it was too much work to provide a build server and so I was on my own. Well, a build server wasn’t really what I was after (although that would be useful for multi-platform projects) and I got the distinct impression that SourceForge staff were people who were content to look backwards and uncomfortable looking forwards. They seemed more concerned with how to ring out more ad revenue from project pages than in actually supporting the people whose projects bring eyeballs to their page views in the first place.

When I brought up my dissatisfaction with SourceForge in casual conversation at the Agile Roundtable, the response was “SourceForge? Who uses that anymore?”. The consensus among those present was that people were moving their open source projects to places like github or google code. I’m a little uncomfortable hosting my project on google code and I’m not that familiar with git (the commands seemed name for convenience to Linus rather than for names that reveal their intent). I participate in a google code project and I noticed that google code is displaying my email address in the clear for every commit that I make. Apparently there’s no way to avoid that unless you had a gmail account before you joined the code project. Hrrrm. Not very friendly, IMO. I get enough spam; I don’t need my email address plastered over every commit on a web page to feed the harvest bots. After that discussion—I value the opinion of my fellow round table members very highly—I had decided that I would definately move my project to some other open source hosting site, but I hadn’t decided where yet.

At the 2009 Microsoft MVP Summit, I attended an extra session on CodePlex. I had previously browsed the CodePlex web site before while looking for some .NET open source stuff and it seemed reasonable at the time. I thought this would be a good way to learn more about CodePlex and its community. The session was very well attended with probably 40 or 50 other MVPs in attendance. Many of them were existing CodePlex users for their open source projects. From the presentation that the CodePlex team was giving, it was clear that they themselves were practicing agile development in the enhancement of CodePlex itself. Clearly, they would understand more directly what I wanted from an open source project, since we were both working in an agile manner.

As the session progressed, they showed us quick wireframe views of possible features and asked for feedback and prioritization of features among the MVPs. I learned that the work item facility in CodePlex lets users vote on bug fixes or features they’d like to see and with community participation, this can lead to a natural prioritizing of outstanding issues without having to explicitly poll your users. Since CodePlex is itself a project on CodePlex this means that you can also vote for enhancements to the system hosting your projects and not just your own projects. At its core, CodePlex runs on a cluster of servers that run Team Foundation Server (TFS). If you have a TFS client, you can manipulate your source code and your work items through that interface instead of using the web interface.

I haven’t used TFS myself, but CodePlex was providing a Subversion bridge that allowed you to manipulate your source files through Subversion. Subversion was the version control system I was already using, so this seemed to be just the thing. So how do I migrate my project over from SourceForge? Well, I wanted to capture all the branches and commit logs of the existing source tree. This proved difficult with the Subversion bridge. The main way that you import/export history in Subversion is through shell access on the machine hosting the repository. That was going to be problematic because the subversion bridge for CodePlex didn’t provide any such view of the repository. I experimented with some tools that attempted to manipulate the repository through TFS directly, but I didn’t have any success. So, I just uploaded a ZIP file of the current source and put the final repository conversion on my “To Do” list.

A year went by and I attended the CodePlex talk at the 2010 Microsoft MVP Summit. Now CodePlex was supporting Mercurial in addition to Subversion as options for the source code of projects. As I recounted my difficulties in migrating my source tree history with Subversion, it was suggested that I might try Mercurial instead. The idea was to make a local Mercurial repository from my remote Subversion repository and then push the changes from my local machine to the Mercurial repository on CodePlex. When I attempted this, it worked flawlessly!

At the Summit, I asked the CodePlex team why they chose Mercurial instead of git or some other distributed version control system and what they thought about competing open source community sites like SourceForge, github, etc. Their responses were interesting. According to the data that they had, people were neither using Subversion nor SourceForge for new projects. Instead they were using a distributed version control system (git was popular among the linux and Mac community, Mercurial was popular among the Windows community) and hosting new projects on community sites that favored their preferred distributed version control client (github, google code and CodePlex). Even before CodePlex supported Mercurial natively, it was possible to interact with Subversion repositories through a Mercurial client. Similar possibilities exist for other combinations of client and remote repository. Because many (but not all) projects on CodePlex are Windows oriented, it made sense to implement Mercurial support on CodePlex first. They saw Subversion and SourceForge as technologies in a clear decline. This was consistent with the views of my peers at the Agile Round Table, most of whom are using git as their version control system and if they have open source projects, they are using sites like github or google code.

The only remaining problem for me was that I had entered quite a bit of requested features into the tracker on sourceforge. How to migrate that information? After digging around on SourceForge, I couldn’t find any interface that would let me export tracker data as XML or even comma-separated value text files. I decided that the only feasible way was to do web scraping to get the data out of their tracker without lots of manual labor. I used a shell script and the lynx browser to extract the data from the SourceForge tracker. From there I will probably cobble together some kind of crazy AutoIt script to bang on a web browser on my desktop to enter in new work items on CodePlex.

All the items that I had in my bug tracker were merely place holders for a “To Do” list of enhancements and the occasional bug. If I had real user activity in my trackers with a variety of attachments and comments, it would be quite painful to get the data out of the SourceForge tracker. You would face this problem as well if you simply wanted to migrate away from the tracker provided by SourceForge and get all your issues transferred to another tracker database like Mantis. It’s surprising that SourceForge has no export facility for its bug trackers; I can’t imagine I’m the first person to want to do this. Then again, given the way SourceForge has been behaving, maybe it shouldn’t be any surprise at all.