Coming and Going

Back Draft

 

Coming and Going

 

By Jonathan Goodyear

 

Back in 2003 (has it really been that long?) I wrote a column entitled Licensed to Aggravate that outlined some of my frustrations with complex licensing schemes used by many third-party component vendors. Since that time, a large portion of the third-party component vendor market (at least for .NET, which is what I concern myself with) has realized the error of their ways, and moved to a singular licensing model with easier XCOPY deployment options. I (as well as my clients) have greatly appreciated this shift in thinking.

 

Most of the time, these components are licensed per-developer, allowing an unlimited number of deployments. This is especially good for consulting companies like mine, because we can obtain licenses to components that we like and re-use them over and over again for each of our clients. Some components use server-based licensing, and allow an unlimited number of developers to work with it on the project. That s not a bad solution for consultants, either, because we don t have to obtain licenses for the components that we use for our clients. It does tend to make deployments a bit more complicated, though, and can end up being too expensive for smaller clients (or when staging servers and Web farms are involved). I m of the opinion that component vendors should give free developer licenses to consulting companies to encourage us to use them, and just collect their fees from our clients who have to purchase licenses to maintain the code that we produce for them but that s another issue entirely.

 

What I want to delve into here is a practice that I ran into on a recent client engagement. This particular client hired us to build them a Content Management System (CMS) for their corporate Web site. They had some specific needs that weren t addressed by any off-the-shelf CMS. One of the more basic requirements they had was the ability to upload and interactively crop images that will be used on the Web site. This was a perfect example of a case where building the functionality ourselves made zero financial sense, so we looked for a third-party component to fill the gap.

 

Luckily, there are quite a few companies that service the imaging market for .NET applications, so we picked one and purchased a developer license. A few weeks later we had finished the CMS, but ran into a deployment problem. Upon contacting support for this component vendor, we were told that not only did we have to purchase a developer license to use in Visual Studio .NET, we also needed to purchase a separate license for each server to which we wanted to deploy the application. I was taken aback. They re getting you coming and going. The vendor noted that this information was stated on their Web site; I checked, and it was although not nearly as obvious as it should be. After all, it s pretty darn important, and I had completely missed it.

 

The vendor then said that this double-dipping practice (he used a friendlier term that escapes me at the moment ... not that I would mention it if I did remember) was common in the imaging component market. I checked around, and found that around half of the imaging component market does indeed employ a similar licensing model. I think this is a shady business practice, and I told the vendor so. I mean, what are the odds that I m going to build an application and not deploy it?

 

It turns out that desktop deployments don t have any extra licensing requirements; only server-based deployments do. In my opinion, the vendor should either sell two different developer licenses (desktop and server) and price each accordingly, or simply average out the sales of each and have one single price that covers both. The second approach is the one that almost every other .NET component vendor on the planet uses.

 

The vendor defended their licensing model, but did agree to give me a 50% discount on the server license that I now needed. Despite that small show of good faith, and the fact that the component did a pretty good job, I cannot in good conscience endorse the vendor here as I do with other vendors of products that I often use and like. Like SourceGear, for instance (http://www.sourcegear.com). They recently released a killer diff merge tool that you can download for free. How do you like that, Mr. Stupid Imaging Component Guy?

 

Jonathan Goodyear is president of ASPSOFT (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, an ASP.NET MVP, a Microsoft Certified Solution Developer (MCSD), and co-author of ASP.NET 2.0 MVP Hacks (Wrox). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish