Component Licensing Confusion

Back Draft


Component Licensing Confusion


By Jonathan Goodyear


I m fairly sure most of you have heard the term re-inventing the wheel. Unless you have a serious case of Not Invented Here Syndrome, you will probably agree with me that it s not such a good idea, either. Rarely in life do we get the opportunity to be the patriarch of something totally new, so when tackling a difficult development problem, it helps to look for a pre-fabricated solution to save both time and money.


That s the main idea behind the third-party control market. It seems like such a simple concept. Shop for a component that does what you need, buy it, and slap it in. Case closed, right? Ahh, if only it were that simple. Unfortunately, there aren t any standards on how components are licensed. A couple of years ago, I wrote about the extraordinary lengths that some component vendors will go to in order to ensure that you have a valid license (see Licensed to Aggravate at That issue aside, it s often pretty hard to tell what type of license you need to buy in the first place. Even if you do figure it out, your options may be less than ideal.


Now, I ll spare a few companies the embarrassment of naming names (they wouldn t make it past editing, anyway), but I ll bet you ll be able to figure out who some of them are if you ve borne witness to their bizarre licensing models that I m about to share with you. For instance, some vendors license components purely on a per-server basis. I hate this approach, because nine times out of 10, this requires you to buy production licenses for your QA server, as well as every single server in your Web farm. You could perhaps convince me that licensing each server in a farm is justified, but I refuse to pay for a production component license for a server that will never actually see production use. It doesn t make sense. I hate inflexible licensing plans.


On the other hand, there are vendors that go to the other extreme. One particular vendor I know of sells nearly twenty different components. Each component can be purchased on a developer-seat basis, a site basis, or an OEM basis. But wait, there s more. Each of those options is further compounded by the fact that you then have to choose between their Professional and Enterprise versions. I don t have my abacus handy, but that adds up to almost 120 options from which to choose. Not even Burger King offers that kind of variety. But wait, it gets even worse. In an effort to encourage sales of multiple products at the same time, the shopping cart page has been arranged into a wizard. As you select different combinations of products, the wizard shows you how much the custom suite will cost, as well as how much money you d save by buying them as a package deal. However, it doesn t explain how those discounts are calculated, so you find yourself clicking endless combinations of checkboxes looking for the best deal. It s the virtual equivalent of clipping coupons and comparing deals, and we all know how much fun that is. The mere fact that it takes a wizard to make a purchase should have tipped these guys off that their system was much too complicated.


Another popular component licensing scheme is to sell them in blocks of developer seats. So, for $500, I can have up to five developers working with the XYZ component. What happens if I hire a sixth employee? BAM! I have to shell out $400 more to upgrade to the license that accommodates up to 10 developers. Next thing you know, I m scalping my extra developer licenses outside the local .NET user group meeting (not really, but you get the idea). You d think that these vendors would sell single-user licenses to help customers fill in the gaps, but if you take a look around, you ll be surprised at how many companies only sell in blocks. This approach also hurts the independent consultant who may want to use one of these components for his or her clients.


There are other crazy licensing models out there, but I only have so much space each month that I can use to opine on such matters. Now that I have thoroughly complained about the current state of affairs, though, it would be remiss of me if I didn t put forth my opinion on how I think components should be licensed. I am inclined to support the per-developer seat model, because it shifts most of the cost to larger development shops who can rightly afford it, and doesn t penalize smaller shops (or independents) with ghastly per-server licensing costs. This also makes deployment a snap, because any complex licensing garbage (I ve given up that fight) is all on the developer s PC, instead of mucking up the QA and production servers.


Volume discounts should (of course) be offered, but forcing customers to buy blocks of licenses (where some may not even be used) is a very bad idea. Vendors should also get out of the business of selling multiple versions of their components. It s aggravating to have to pay a much higher rate for the Enterprise version of a component because there is one feature that I need that isn t in the Professional version. Option shopping makes sense for physical goods like cars, but not for virtual goods like software that have zero per-unit costs. I have to think that this would streamline the support process, as well.


What I m really asking for is simplicity mixed with a touch of common sense. That s a recipe I think that we could all buy into.


Jonathan Goodyear is president of ASPSoft (, an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at




Hide 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.