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. 

I may be a little biased because they're ours, but our new Calendar Controls really are the best looking ones I've seen.  You can now add a calendar to your managed app that looks just like the Outlook calendar.

Seems like it took forever, but we've finally released the SDF 2.0 Extensions for Visual Studio 2005.

For more info on what exatly comes with the new SDF Extensions, click here.

I came across this article while doing some research.  It's well worth the read for anyone doing any kind of development.

Microsoft has published a new white paper on the Micro Framework information page.

Ever want to make all CAB file installs on your device be silent?  Simply add the following registry key to your platform:

[HKEY_CLASSES_ROOT\cabfile\Shell\Open\Command]
    @="wceload.exe \"%1\" /nodelete /noaskdest /noui"

Just as a mental exercise, today I decided to try to write a single method that would allow me to return information about the currently running assembly as a string.  One method needed to return the copyright info, the company info, etc.

The end result is this simple function:

public string GetAssemblyAttribute<T>(T attributeType) where T:Type
{
    object attribute = Assembly.GetExecutingAssembly().GetCustomAttributes((T)attributeType, false)[0];
    return (string)attribute.GetType().GetProperties()[0].GetValue(attribute, null);
}

And calling it is this easy:

string s = "";

s = GetAttribute(typeof(AssemblyCopyrightAttribute));
s = GetAttribute(typeof(AssemblyCompanyAttribute));
s = GetAttribute(typeof(AssemblyDescriptionAttribute));
s = GetAttribute(typeof(AssemblyProductAttribute));
s = GetAttribute(typeof(AssemblyTitleAttribute));
s = GetAttribute(typeof(AssemblyTrademarkAttribute));

Now why it has to be this ugly I'm not sure, but isn't reflection a hoot!? 

As I get older and busier I've found that I seem to have a hard time keeping up with artists that produce music I like.  The radio only plays familiar new stuff over and over and is a poor way to get informed, and I don't really have the time to go blog hunting to find someone with similar tastes and then look at their play lists, then look at each band.  I want simplicity.

Today I found Pandora, and I found it works beautifully.  Basically you put in a group or song you like and it just starts playing random songs that it thinks you might like based on that.  You can tune it like a TiVo - telling what you do and don't like (though I've not had to say no to anything yet).  Even more impressive is that it will give you an explanation of why it picked the song it's playing.

They have a revenue model as well - you can buy the song directly from iTunes or the entire album from Amazon from the interface, which means that they may stay around a while to continue bringing us music.