We’ve recently released SDF 2.0 and our so-called “SDF 2.0 Extensions for Visual Studio” and with the release came the expected comments like “Since you’re now selling your code, shouldn’t you change your name from OpenNETCF to something else.” Well I’d like to give you some insight onto our rationale for charging for the SDF.
First, let’s look at what we’ve actually done as far as licensing goes. The SDF is available as basically 2 separate items. There are the compiled binaries and then there are the “Extensions for Visual Studio.” You can download the binaries from our site and develop using them, though you won’t get Intellisense and nice designer support. You can ship them, at no cost at all, with your application to any number of customers. There is no cost for this.
The Extensions add a few niceties – you get intellisense and designer support. You get new templates added into Studio. You get some Studio menu plug-ins, like a link to our online Bugzilla database. You also get the full source code. The extensions sell for $50.00 for a single developer, which even if you get paid really, really poorly, is only a couple hours wages and will save days of work. That’s our direct value proposition: for $50 you can get something that would have taken you weeks or months to develop yourself.
The source license is a little different than the SDF 1.x license as well. You can now build the SDF into your app directly and you don’t have to provide any copyright info, headers or anything to indicate that you used the SDF. While not a big thing, there have been customers that have said that was, in fact, a problem.
So, why the decision to start charging anyway? The answer in simple terms is growth.
First, we needed to grow the SDF itself. We needed to grow its feature set, since CF 2.0 made a lot of it obsolete. We needed to grow its reliability by building test harnesses and functional tests for each piece. We needed to grow the documentation by actually filling in XML comments on a lot of code. SDF 2.0 took a lot of work to build, test and debug – more than all of the 1.x versions – and to put it simply, motivating people to do hours and hours of work for nothing is difficult. It’s even more difficult when they’ve already been doing it for a few years.
Second, we needed to grow our market. While it may come as a surprise to individual and small-shop developers, large enterprises are wary of anything that’s free. In fact, many won’t adopt anything that they don’t pay for because they feel that without a revenue model there can be way to fund development of support. To help build our day-to-day business of consulting and development, we need visibility and penetration with companies that routinely buy these services. The SDF is essentially a marketing vehicle in that regard. We feel that $50 makes the SDF seem like a more “real” product to an enterprise, while not placing undue burden on the small guy’s budget.
Third, we needed to grow our revenue so we could grow OpenNETCF. OpenNETCF is now a real company, with real developers who have real families that have real bills. While we all love the idea of free and open, we also know that to continue work we need to at least be able to pay for web hosting and the like. Don’t get me wrong here; the SDF is not a profit center. We’re not going to get rich, or even move up an income bracket due to SDF sales. With the amount of time we have into it it’s unlikely we’ll even approach break-even, however the “donation” model fails miserable. In the 2 years we were accepting PayPal donations we got less that $100 in total.
This move was really about the survival of the SDF and OpenNETCF as a whole and we sincerely hope that we don’t turn too many SDF users away with the new model. Sure, we know we can’t make everyone happy and there will be people out there that are angry that they now have to pay for what we have, but the hope is that the large majority of users will understand, even if they don’t decide to purchase the Extensions.
While we’re not as “Open” and some would like, we still believe in the concept of openness, which is why we still provide the source for the SDF when you buy it (which most tool vendors do not, I’d like to point out). We still have the RAPI desktop library and the serial/GPS libraries which are free and open, and we’re actually looking at some other new projects that we may release as community projects in the future.