Is SharpMap Viable?

It seems there’s been a little more buzz about SharpMap lately and some folks have been doing some fact-checking with James offline. He deftly spun the question of “viability” into “popularity” by citing CodePlex statistics. Can’t say I blame him. The question of viability when it comes to open-source, especially smaller projects, can be tough to quantify. Say what you want about ESRI‘s licensing, tech support and whatever else; this much you can count on: they have genuine motives (profit, competiton) to keep their product line moving forward. The motives behind open-source can be a little more nebulous and they run the gamut.

So back to SharpMap: I am using it on a project but I am not a participant in the SharpMap project itself, aside from one minor contrib. I am a consultant and still do most of my work in the ESRI realm. I’ve been looking at open-source tools as an alternate technology path where they make sense and have been impressed with the capabilities of many of the tools. While my recent post referred to the fact that was feeling my “MO vibe” again while working with SharpMap, I didn’t go out specifically seeking a replacement for MO or Engine.

SharpMap could help me meet my project requirements. First of all was performance. By using SharpMap, I was able to eliminate two pieces of middleware (ArcGIS Server and ArcSDE) between my database and the application. This was a good thing for us. It also had the added benefit of taking COM interop out of the loop. Secondly, I had to be able to render the map in a native WPF display. I haven’t found anything that does that so the open-source nature of SharpMap was a good thing. I could see the entire behavior of the library from the time it connects to the database to the time it renders. This gave me what I needed to start down the WPF path (which I’m not completely down yet). A black box library would not have made sense here. Next, there’s support. I don’t have a dependency on a vendor for that. In the discussion on James’ post, the question was posed “who do you call when a critical bugger is mucking up a mission critical app?” Well, in this case, I call me. If I hit a snag, I fix it. If the fix involves the core library, I submit it as a contrib and move on. I have enough confidence in my own ability (and that of the other developers I work with) to do that. Lastly is deployability. I can include SharpMap in the image of the system baseline and not have to worry if it gets over-installed or whether I’ll need to activate any licenses. It’s “give and go.”

So back to the question of viability. Measuring viability of an open-source product requires a little bit of homework. I have no magic formula by which to measure but here are the factors I generally use. They may or may not work for you and I don’t profess them to be authoritative but these factors serve as a guide for me. In no particular order:

1. How many core developers does the project have? Generally, the more the better but there is potential for a “too many cooks” issue as well. Basically, the more complex the project, the more developers you may need to segment it off and keep it moving forward in a timely fashion.

2. How many contributors or contributions does the project have? Contributors are generally not core developers but people who have used the product and either extended or improved it in some way. Existence of a healthy contributor community is an indication of the level of enthusiasm for the product. They also serve as a potential pool from which to draw if core developers drop out.

3. Are there related projects? For instance PostgreSQL has the related PostGIS project. There are several projects inter-related with SharpMap (NTS, SharpGPS, etc.). This gives a good indication that others also feel confident about the project you are evaluating.

4. Does the product have an active community? Generally, the major project-hosting sites (SourceForge, CodePlex, Google Code, etc.) have some form of forum feature. If the project has an active forum, that’s probably a measure of the user community. Products that get used will continue to be developed so this can give you an idea if the project will be around for a while. I recommend spending a lot of time in the forums because you can learn a lot. What is the general tone of the discussion? Are most of the posts complaints? Bug reports? Compliments? What is the general tone of the responses from the developers? Are they cordial? Are they helpful or do their responses tend to be along the lines of RTFM? If you sense a lot of negativity in either the posts or the responses, it’s probably not a project that’s long for this world.

5. Does the code build? If not, it’s probably too immature. The concepts of alpha and beta can be a little nebulous with open-source. I generally hook in at a given build and run with it. If there’s a “release” every so often, fine, but I don’t live or die by them. For instance, SharpMap has technically been at version 0.9 for a while but there have been a few builds and it’s improved with each build.

6. In what would seem to be a contradiction to what I just said, does it have at least one release under its belt? Generally, I want at least one release before I adopt. This is an indication that the developers felt like they had something usable and functional enough for whomever the target audience was. Prior to the first release, you can end up with a lot of stubs, bootstraps and unit tests.

7. Does the project have one or more corporate sponsors? Hey, developers have to eat. If someone’s paying the bills for the project, then the developers are more likely to stay engaged long-term. That said, this can be a very hard thing to find out because a lot of companies have different motivations for sponsoring a project and they may not always want their involvement made public. For instance, I have no idea if SharpMap has one. (Update: SharpMap is sponsored by Enkindle Software)

8. How well is the code organized? This is a lesser issue but one that has to figure into your risk assessment. A project can pass all of the other tests with flying colors and still go belly up. So the question you need to ask yourself is: If this project goes away tomorrow, can I maintain the source code for myself in order to keep my project going? Code that’s not well-documented and organized (by whatever your definition of those terms is) is probably not something you want.

So those are my rough guidelines. As you can see, there’s some subjectivity in there. Make of them what you will or toss them aside at your leisure but they’ve worked for me. Evaluating open-source products for real projects is not for the faint-of-heart. Put your best and brightest on the task. I consider an open-source project that measures up favorably to most of those to be viable and worthy of inclusion in my toolset as a consultant. SharpMap seems to measure up well and so I consider it viable enough to actually use.