Getting paid for your SharePoint software, part 2

This is second part of my series on getting paid for your SharePoint software. If you have not already done so, please read part 1.

In part 1, I discussed how you need to be able to do four things to transform a piece of software into a product that you can get paid for:

1. Distribute the software
2. Deploy the software
3. License the software
4. Copy protect the software

Of these, licensing and copy-protecting the software prove to be the most difficult on the SharePoint platform. Please read part 1 of this series for details on why. Because licensing and copy-protecting software are closely related, I will discuss various options for structuring SharePoint software and their impacts on licensing and cop-protecting the software.

 

Option 1: License and copy-protect the installer

You could spend a lot of time, effort, and money trying to create the "un-piratable SharePoint app". And what if it doesn't sell? You spent all that effort protecting something people don't want. Consider incorporating the licensing and copy-protection into the installation utility only, and not the rest of the application.

• Licensing - Package your SharePoint application WSP with SharePoint Solution Installer. Add a wizard step to call your license validation component. You can check for things like the number of servers in the farm, validate the entered license key with another piece of information like the person's email address, check whether the farm is WSS, MOSS Standard, or MOSS Enterprise. This provides a minimal level of licensing validation but does not allow for things like activating features over time, trial-ware, responding to changes in server count, users count or other changes in the farm.
  
• Copy protection - There is very little in the way of copy protection with this method. There is nothing to prevent a malicious customer from taking the files and assemblies from your application and manually copying them to another farm.
  
• Level of effort - This is by far the fastest option to implement as it does not require any changes to the application itself. You could easily complete this within a few days to a week.
  

Option 2: License and copy-protect the application assemblies

This option is more involved than option 1, because SharePoint lacks the infrastructure to easily deploy the types of components that are typically present in off the shelf license validation tools. Please read part 1 of this series for details. I would only recommend this option if you already have software that is either selling or broadly distributed; i.e. you know people like and user your software.

• Licensing – You have a number of options here since the licensing can now be more deeply integrated into the application logic itself. You have the potential to activate different features based on the type of key the user enters, implement time-limited or feature limited software (trial-ware), or just about anything else you can imagine and your license validation components support. The down-side: you have to modify your application code, perhaps extensively.
  
  
• Copy protection – This option has a better copy-protection story. Since you are modifying and recompiling your application assemblies, you can integrate the copy-protection features of your license management components into the assemblies. However, this generally means that you need to issue and store environment-specific keys, like Windows and Office does. For example, the user enters a product key that is combined with information like the farm ID or farm server hardware signature to store an activation key (not the original product key) on the customer’s environment.
  
  The trick is to store those activation keys securely and prevent the software from being moved from one environment to another. One difficulty with environment-bound keys is that you will need a central repository that you control that will be used to keep track of which product keys have been activated on which environments. This means that the customer’s SharePoint will need connectivity to the Internet to activate the product keys. But, the servers will only need Internet connectivity when the server or farm-bound key is being activated. This is what key activation schemes like the one that Windows uses do. The problem with this scheme is that you have to be able to handle servers that don’t have Internet connectivity. Microsoft handles this by providing a call-in number.
  
  
• Level of effort – The level of effort here is significantly higher than option 1. You could easily spend anywhere from a couple of weeks to a few months retooling the application to incorporate license-awareness and writing the necessary infrastructure code to deploy, manage, and revoke licenses. You will need to build or procure a license activation repository. I have used Quick License Manager from Interactive Studios with good results. They provide a license management runtime that can handle environment-bound keys and a license activation repository. For an extra fee they will even host the repository for you. Also, because this option requires modifications to the application, you will need to do full regression testing on the application functions and the deployment, updated, and un-installation processes.
  

To be continued in part 3…

Check back soon for the third article in the series. In part 3 of this series, I will show how some creative changes to the application design and to the business model for the application can give you the best of all worlds.

WCF errors from SharePoint event receiver

I find it strange that I am writing this post as it would never have occurred to me that I would run into this particular issue. I’ve seen several articles on getting SharePoint to host a Windows Communications Foundation (WCF) service, but I have not seen very much on issues when SharePoint needs to invoke a WCF service.

I had a WCF service running with a SharePoint farm. Lets call that “Farm A”. I had a SharePoint event receiver running on a remote SharePoint farm. Lets call that “"Farm B”. I wanted a very simple procedure to happen: when a list item gets added to a list in Farm B, I wanted to invoke the WCF service running on Farm A.

Simple right? I certainly thought so. I followed excellent article series on hosting WCF services in SharePoint by Sahil Malik, a fellow SharePoint MVP. I deployed the service to Farm A and tested it using a simple Windows Forms application test harness. Everything worked as expected.

So then I copied over my WCF client code from my working test harness to my event receiver running in Farm B. And then the errors started.

When I have the IIS in Farm A configured to use NTLM authentication, I got the error:

The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'

When I have the IIS in Farm A configured to use Basic authentication, I got the error:

The HTTP request is unauthorized with client authentication scheme 'Basic'. The authentication header received from the server was 'Basic realm="192.168.161.135"'

Now before jumping to the conclusion that there must have been something wrong with my WCF service configuration in Farm A or my client code in Farm B, let me again say that I had been able to successfully invoke the service from my test harness using both Ntlm and Basic authentication schemes using the IP address. So clearly, there was something happening between the combination of the WCF client code and the SharePoint event receiver framework that was invoking the WCF client.

Unfortunately I could not fix the problem as I would have liked, but I was able to find a workaround. Rather than use the WCF client proxy (Add Service Reference in Visual Studio), I used a Web Service client proxy (Add Web Reference in Visual Studio). The only thing I had to change in the WCF service configuration on Farm A was change the message encoding (messageEncoding) format from Mtom to Text. On the Web Service client running in the event receiver on Farm B, I had to specify that the message format was SOAP 1.1 (System.Web.Services.Protocols.SoapProtocolVersion.Soap11).

Certainly this is not an ideal solution, but it allows me to proceed with my project. Here’s hoping that SharePoint 2010 and WCF play a little more nicely together :)

Why SharePoint Scares Me … commentary

I recently read a post by Peter Campbell titled “Why SharePoint Scares Me”. Now being a Microsoft SharePoint MVP, you might think I’m about to go into a scathing criticism of Peter’s post. But I won’t. In fact, you may be surprised when I say that I liked his post very much.

Peter’s post was an honest and objective view on SharePoint from the perspective of someone who is neither a Microsoft zealot nor an oppositionist. Peter seems to be someone who doesn’t really care that much about the tech but is looking for something to get the job done with minimal upfront and ongoing investment. I run into similar conceptions about SharePoint very frequently. This is exactly the type of person we (the SharePoint MVPs) and Microsoft need to educate. 

To summarize Peter’s post, it conveyed concerns about SharePoint’s complexity, costs, learning curve, and operational impact. Unfortunately a lot of people share Peter’s viewpoint. I wanted to share my perspective on some of his points...

"advanced programming and integration with legacy systems can get really complicated"

This is true of all technologies, not just SharePoint. SharePoint actually has several tools that can make the job much easier. For example, many times you can implement a no-code integration with an external / legacy system using SharePoint Designer 2007 and the DataForm (aka DataView) web part. This does not require the more expensive SharePoint enterprise CAL.

"MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app"

CMS was integrated, but the integration is better than one would think. It works very well for intranet and extranet scenarios. SharePoint for Internet sites can still be a challenge, but a fair amount of large Internet sites use SharePoint today. Check out this impressive list of public Internet sites using SharePoint from wssdemo.com.

"Without careful planning, Sharepoint can easily become a junkyard"

This is true of any content repository. The integrated search helps a great deal with content discovery, especially for new users, and the content expiration and records management features help to keep archives from cluttering up the works.

"Licensing for use outside of my organization is complicated and expensive"

Check with your MS sales rep. Microsoft has many programs to help smaller organizations qualify for better pricing, including BizSpark. BizSpark offers relatively new and small business free software for a period of three years! it’s a fantastic program.

The unlimited license is typically used only by public Internet sites that don't want to or can't track individual users. Intranets and extranets should use the per-user license. You may even get a volume discount as well. You can also start with Windows SharePoint Services (WSS) for core collaboration and document sharing, and move to MOSS later, if you need to. WSS is included with the Windows Server license.

"Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are significantly high"

The great thing about SharePoint is that you can start small and scale out as your needs grow. Start with a small pilot group of users. If more people want to join in (and they will once they see what SharePoint has to offer), add hardware then. You can even scale up servers without taking the farm offline.

While bandwidth can be an issue, especially for transferring large documents, this is true for any CMS.

<Shameless-plug>
Black Blade Associates (my company) has a product called SharePoint Zip. SharePoint Zip allows users to transfer files between SharePoint and their desktops as compressed Zip files. Users can transfer individual files, folders, or even a complete document library with a single click. Users can also upload multiple files as a compressed Zip file, which will be expanded into the document library. No additional client software, ActiveX, or plug-ins required.
</Shameless-plug>

"The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption."

This actually works better than storing the documents on disk. You are able to leverage database transactions, load balancing, backup, maintenance, and failover to guarantee uptime and ensure disaster recovery. SQL Server has made great gains in storing BLOBs, and SharePoint continues to benefit from those gains.

"I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does"

I began my IT career doing enterprise application integration. I can tell you from experience that getting multiple applications to talk to one another in a way that is meaningful to your end users is always much more expensive than procuring one, integrated application. You're generally looking at a 3X cost increase for the labor costs to do the integration. Also, don’t forget to budget extra time on top of deploying the systems to do the integration work.

"I might lose all of that out of the box integration with my MS network"

Don't underestimate the costs of losing integration with the Office desktop applications with which your users are familiar. User productivity loss and user training costs are two very high hidden costs to deploying any CMS or collaboration system. SharePoint minimizes those costs by leveraging the expertise and familiarity users already have with the Office desktop applications.

All that said, I don’t want to give the impression that SharePoint is perfect or that Peter’s points are not valid. SharePoint is not perfect, and Peter has definitely done some due diligence before implementing a core business capability for his organization. However, when compared to the alternatives, SharePoint is a very capable and cost-effective offering, especially when you factor in comparing the hidden costs of user training, user productivity (you know, the reason you’re planning on deploying a collaboration or CMS in the first place), ease of scale-out, and general management features. Even CMSWire, a site typically critical of SharePoint, posted a lengthy reference to a Gartner report positioning SharePoint 2007 in the “magic quadrant” for enterprise CMS. Considering that SharePoint is sharing the position with products that have much higher price tags that is a high praise indeed.

By the way, if you have not already done so, you should really check out the SharePoint 2010 videos Microsoft just posted. They show many improvements to the underlying SharePoint infrastructure and development experience, and the videos address many of Peter’s concerns.

Microsoft releases SharePoint 2010 sneak peak videos

This is for everyone chomping at the bit to know more about the new version of SharePoint, SharePoint 2010: Microsoft has released three sneak-peak videos on SharePoint 2010. Check out the videos here:
http://sharepoint.microsoft.com/2010/Sneak_Peek

There are three videos: an overview video, one target for IT pros, and one for developers. Now, I know what you’re thinking: oh great <sigh>, these are more stupid animated Flash movies from the marketing department that are packed full of moving document, people and web page icons but really have no useful information.

Not so! These videos have some real meat them. You can actually get a glimpse of what working with some of the new and augmented features of SharePoint 2010 is like, including what it takes to develop applications for it.

Great together: Windows Live Write and Blogger

I’ve had my blog on Blogger for a few years now. I’ve tried various methods of posting blog entries to Blogger, including Microsoft OneNote / Word. That method worked ok, but including rich media was always a manual and painful process.

I then started using the Blogger web user interface. It worked well most of the time. Including rich media was much easier than with Word. But, due to glitches between the web user interface, my browser, and / or network connection (still not sure exactly what happened) I lost several posts. I’m not one of those natural writer types who can whip out a post in a few minutes. Writing is an arduous, and sometimes painful process for me and my wife (she has to listen to me complain about it), so losing even one post was a big setback.

I’d seen Window Live Writer a while ago, and even tried it in passing, but it did not integrate well with Blogger. But, I am happy to report that the recent update I downloaded is a huge improvement. If you are using anything older than version 14.0…., download the latest version of Live Writer and give it a shot. Inserting images and screen shots (which I use a lot!) is incredibly easy. I just did a print screen from Windows, and pasted this image directly into my blog post.

No messing around with saving the file locally, then uploading, then re-linking into the post. I can easily control the size of the image, various effects, and text wrapping.

The best part is that I can open previous blog posts and drafts directly from Blogger to make updates. Live Writer will even import my blog template so I can get an accurate preview of my post as I’m writing it.

There are lots of other great reasons to give Windows Live Writer 14 a try, especially if you have tried a previous version and have been unimpressed. Go ahead, give it a shot. Download Windows Live Writer today.

Getting paid for your SharePoint software, part 1

What's the issue?

If you're reading this post, you're already aware of the tremendous velocity with which SharePoint grown in the web-based collaboration market. You are probably also aware of the huge community of application developers, IT pros, UI designers, information architects, content managers, and users that have sprung up around this extremely popular product. I sure did. But what really struck me was how few add-on products there are for such a popular collaboration platform. Now sure, there are lots of free and open source tools and utilities out there, but not many "real products"; you know, the kind that you can buy and actually get support for.

That's a big barrier to SharePoint adoption. Most companies don't have SharePoint developers and don't want to install some code they find on Codeplex in their production environment. Real organizations want real software that comes with real support. Unfortunately, providing real support costs money. That means that the person writing the software needs to be able to make at least enough money from the software to cover the support costs, including coming out with updates.

In order to get paid for your software and provide support for it, you need to be able to:

• Distribute the software
• Deploy the software
• License the software
• Copy protect the software

If you can't do those four things, you don't have a product; you have a utility for which you will not likely get paid, and for which you will not likely be able offer support.

Ok, so that's software development 101. Back to the main question: Why are there so few real SharePoint products on the market? Based on the size of the SharePoint community one would think there would lots good ideas for SharePoint software for which people would gladly pay. Distributing software is fairly easy, just post it on a web site, and let people download it. Don't have a web site? The list of free web site providers is too numerous to mention. Deploying SharePoint software is not hard. SharePoint has a deployment framework that makes use of Cab files with a ".wsp" extension, called "Solutions". there are several tools to create WSP files and deploy them with a GUI. Check out WSP Builder and SharePoint Solution Installer.

It turns out that the hard part of getting paid for your SharePoint software is the last two items: licensing and copy-protecting the software.

Licensing

Lets talk about licensing fist. You don't want to write your own license management software. It is much better to use some off the shelf software for this purpose. License management software is relatively inexpensive and does a much better job of storing the license keys securely than you will likely do. The problem is that most of that software requires the deployment of un-managed (native) DLLs or COM objects and direct registry access on each server in the SharePoint farm. Un-managed DLLs require a different version of the DLL depending on whether you are deploying to a 32-bit server vs. a 64-bit server. COM objects need to be registered on each server in order to function. SharePoint does not have a good mechanism for easily deploying and managing these types of components. Yes it can be done, but you will likely spend as much much writing the infrastructure code as you did creating the actual software.

Copy protection

Copy protection is also problematic for SharePoint applications. Yes, you can strong name your assemblies, and with a licensing and obfuscation mechanism, secure them and bind them to the farm for which they were purchased. The problem is that a real SharePoint application is not just a set of assemblies. In fact, it may not have any assemblies at all. Here are just a few types of objects that must be stored in clear text on each web server:

• Site and list definitions
• Content types
• Features
• ASPX pages

Even if you are able to secure your assemblies, the bulk of your SharePoint application may be required to be unprotected. If you can not copy-protect a large portion of your application, you may still get some sales, but will likely lose significant revenue from people using pirated copies.

To be continued in Part 2...

Rest assured that there are solutions to the problems of licensing and copy-protecting your SharePoint software. I will discuss several options in part 2 of this series.

Speaking at the SharePoint Best Practices Conference

I'm very excited to speak again at the upcoming SharePoint Best Practices Conference in the Washington, DC area. The conference will be August 24-26, 2009 at the Hyatt Regency in Reston, VA, a short hop from Dulles International Airport (IAD).

I'll be speaking about "Using Service Oriented Methodologies to Create SharePoint Products", a topic that's near and dear to my heart. If you have an idea for a SharePoint-related product but don't know how to make that idea pay, or you already have some SharePoint software that you would like to take to the next level, this is the session for you. Here is full abstract:

This presentation focuses on applying development methodologies and software architectural concepts of Services Oriented Architecture (SOA) to the task of creating complex SharePoint applications. We will see how a SOA approach can help us achieve a stable and scalable product, decrease support and maintenance costs by decreasing the product’s complexity, and greatly simplify the copy-protection and licensing requirements for the product.

While the topics in this presentation are of great benefit to new software development efforts, they can be even more valuable to organizations with an existing product set. We will look at a case study of how a traditionally architected application was converted using the SOA tenets discussed in this presentation and the benefits that conversion brought about.

Oh, and did I mention that Arpan Shah, Director of the Microsoft SharePoint Team, is giving the keynote?! Take a look at the great list of topics and speakers. Register today for what is sure to be an exceptional conference!

Bluetooth not working after Vista resume from sleep

I've had a problem with my Bluetooth on my Vista x64 laptop ever since I got it. Everything would work fine when the laptop first booted. However, when I suspended the laptop and subsequently resumed, non of my Bluetooth devices could connect to it. I was stumped. I tried updating my Bluetooth drivers, Windows patches and service packs. I've had the problem since RTM, with service pack 1 (SP1) applied, and the problem is still there with service pack 2 (SP2) applied.

I've seen a lot of people having similar issues. Unfortunately, all I can contribute is a workaround. That said, the workaround has worked well enough for me, but only because I do not typically need by Bluetooth devices all of the time. You'll see when I mean soon.

The workaround is simple: after I resume the laptop from a suspended state, I disable and re-enable the Microsoft Bluetooth Enumerator driver in the Vista Device Manager. The process takes about 1-2 minutes, so it would be quite a nucense to have to do it every time I resumed my laptop.

Here are detailed instructions on how to disable and re-enable the Microsoft Bluetooth Enumerator driver:

1. Click on the Vista Start button
2. Right click Computer
3. Select Manage
4. Select Continue on the User Access Control (UAC) dialog box
5. Select the Device Manager node from the tree view on the left
6. Expand the Bluetooth Radios node from the devices tree node on the right
7. Right click Microsoft Bluetooth Enumerator
8. Select Disable
9. Select Yes on the confirmation dialog box
10. Wait for the device to be disabled
11. Right click Microsoft Bluetooth Enumerator
12. Select Enable

You should now be able to connect your Bluetooth devices to you Vista computer.

You can see this is quite an annoying process, but it has worked fairly consistently for me. I have Vista x64 Business Edition running on an HP Compaq 8710w Mobile Workstation with a Broadcom Bluetooth driver.