Open source on the .NET platform is a topic I’ve been thinking about for awhile. My current boss has made it a point to try and use open source applications built with .NET whenever possible. This is the first in an occasional series of posts on the topic.
A good definition of the term “open source” comes from Vaskin Kissoyan of Lokion, Inc.. Here’s the software developer aspect of the full definition:
“Open Source Software allows a developer to contribute to an already existing product or application, it also provides a rich set of library code (basic functionality) effectively giving you an almost unlimited amount of blocks upon which to build your applications. The OS community fosters reuse so there is no need to re-invent the wheel – a major problem for all developers before the dawn of Open Source.”
How well does this definition apply to some of the software built using .NET since the year 2000? In some respects, it fits quite well. When it comes to library code, Microsoft has provided Application Blocks, then the more robust Enterprise Library. Microsoft has also done a good job of providing reference applications as starting points for future development. This is a practice I first took advantage of during the Windows DNA days when I used the Fitch & Mather Stocks application as the basis for an online recruitment tool I built for Ciena in 2001. Since that time, sample applications like Duwamish Books and a myriad of starter kits have been the basis for many custom development efforts.
The Issue Tracker starter kit was the first open source .NET application our group at Aspen Systems (now Lockheed Martin IT) tried to use. The group lacked a formal, centralized way of tracking bugs in the software we developed, so my manager saw it as a no-cost way to build our skill with C# (it’s also available in VB.NET) and .NET and improve our development process.
Looking back on the experience, we should have answered the following questions before we moved forward with the IssueTracker starter kit:
- Is open source the best choice for this application (buy versus build/extend)?
- What platform are your developers most skilled at building for?
- Is the best open source application on the .NET platform?
- Is it our goal to re-sell an application we’ve extended?
At the time, I could have gone either way on whether an open source application was the best choice for issue/bug tracking. There are tons of commercial, closed-source options with plenty of functionality. One such application is FogBugz. The latest version has great e-mail integration, discussion groups, source code control integration, support for release notes, RSS and more. It can get expensive, but selling custom software for a living should mean that we recoup those costs.
Even if there was no willingness to spend money (and there wasn’t) and open-source was the direction chosen, Bugzilla is used by enough companies and organizations (including Id Software, NASA, and Akamai) that we should have considered it far more strongly than we did.
We were (and still are) primarily a Microsoft shop, so the developers were most familiar with that platform. Unfortunately, too many of them were new enough to ASP.NET that they wrote applications the same way they would have in classic ASP. This was probably why boss felt the application would be a good learning tool.
When it comes to open source, the odds that the best solution will be written in .NET are low. None of the open source bug/issue tracking solutions written in .NET that I was able to find came anywhere close to Bugzilla or FogBugz in user interface, functionality, or documentation.
We weren’t going through the trouble of extending Issue Tracker because we wanted to re-sell it. It was (and is) strictly for internal use. From my perspective, the only reason to assign people from revenue-generating projects to extending this app was if we planned to re-sell the resulting application.
At the time, I believed we made the wrong choice in trying to turn Issue Tracker into a production system. The year that has past has only strengthened that belief. The resulting application is regularly changed and updated to accomodate requests from any number of people. It takes development resources we really need for projects that make the company money. It still lacks useful features that can be found in more mature products (both open source and COTS) .
In my next post on this subject, I’ll examine how these four questions apply to a more robust open source .NET application: Community Server.
So far, the best OSS I’ve seen for DotNet has been in plumbing libraries. I like the Application Blocks, though I feel they are a bit bloated and too interconnected personally.
Gentle.Net is a GREAT OSS library for .NET ORM. Using Gentle and the OSS MyGeneration templates, you can whip up an ORM in a matter of minutes thats very flexible and easy to tweak. I’ve used it on two (soon to be three) projects and its been nothing short of magic. However, the folks working on it actively total just a handful and v2.0 is taking a while to come out. I would be jumping in and helping myself if I weren’t so danged busy myself. (thankfully, Gentle saved me probably hundreds if not thousands of hours of code and confusion since I’ve started using it…)
To be honest, I haven’t seen any OSS .NET apps that have blown my socks off. But I haven’t honestly been looking too hard either. I think there’s a different mindset – especially since by and large, .NET apps aren’t as portable as Java, PHP, Ruby, or Python.
Dave,
I agree with you on the mindset difference between .NET open source and *nix-based open source. In addition, it appears that the vast majority of non- .NET open source has had a lot more eyes on it and is far more battle-tested than their .NET equivalents.