Table of contents

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.

In part 2, I laid out two options that address licensing and copy-protecting SharePoint software:

1. Licensing and copy-protecting the installer
2. Licensing and copy-protecting the application assemblies

While the first option is the easiest way to get started, it also provides the least amount of protection and capabilities. The second option is what you would ultimately want to get to, but it can require a significant level of effort to implement, somewhere between several weeks to several months.

In part 3 I showed how we could use a services or cloud computing application architecture to give us additional licensing and copy-protection options beyond what I covered in part 2. Unfortunately, we uncovered new challenges that arise from this architecture, namely:

1. Customer’s WAN bandwidth limitations
2. Security and multi-tenancy concerns about the hosted service
3. User context maintenance and single sign on (SSO)

So does that mean that a services architecture just exchanges one set of problems for another? Not necessarily. In fact, we can see that all of the issues arise from the fact that the service was hosted outside of the customer’s environment and shared among many customers. Let us examine a an alternate approach where the service the web parts access is hosted not on the Internet but in the customer’s network. My colleague Bradley Smith termed this approach as Localized Software as a Service (LSaaS).

Option 4: Localized Software as a Service (LSaaS)

The LSaaS application architecture leverages the benefits on services oriented architecture (SOA) and cloud computing application delivery models. However, LSaaS extends “the cloud” into the customer’s data center. Whereas a SaaS software delivery model requires that all service requests traverse the customer’s WAN to the service vendor’s Internet-based service instance, LSaaS instantiates one or more instances of the service in the customer’s datacenter.

The main advantage of LSaaS over traditional SaaS is that LSaaS gains the benefits that SaaS offers in terms of ease of licensing and copy protection, but LSaaS mitigates the issues that arise with a pure SaaS approach, namely:

• Limited WAN bandwidth
• Risks of multi-tenancy
• Loss of user context when invoking the service

For a more detailed description of these potential issues, please see the “All services all the time?” section of part 3 of this series. Let’s see what our licensing and copy protection options look like:

• Licensing – LSaaS licensing options are very similar to the SaaS options discussed in part 3. Additionally, LSaaS software delivery schemes also allow for service-instance-based licensing models. The idea is that each instantiation of your service running at the customer’s site can deliver a well-defined, quantifiable amount of service capacity. If the customer needs additional capacity, they will require additional instances of the service. Each additional service instance requires the customer pay an additional fee.
   
  The key to making this licensing model work is that the service instance must deliver a predictable, quantifiable level of service capacity. How you define the capacity depends on what your service does. Popular capacity quantifiers include data storage, processing speed, processing throughput,  Here are some examples of companies using service-instance-based license models to deliver their software as LSaaS:
   
  • Black Blade Associate’s docBlock Ascend (disclaimer: I work for Black Blade)
     
    The docBlock Ascend provides virtual document processing to the SharePoint platform. Black Blade charges a flat fee for each docBlock server appliance. Each appliance has two load-balanced processing modules. For the purposes of licensing, you can think of each processing module as a virtual document service instance. Each processing module (service instance) can process 4 virtual documents per minute. “4 virtual documents per minute” is the quantifiable service capacity per service instance.

    If the customer needs to process more than 8 virtual documents per minute, they must order additional docBlock devices. There are no per-user, per site collection, per SharePoint server, or any other types of additional fees or license complexity. Simple huh?

  • Google Search Appliance

    The Google Search Appliance (GSA) provides enterprise search capability for a variety of content sources. Each GSA is a single service instance and can index 1,000,000 documents, the service capacity. If a customer needs to index more documents, they buy more GSAs.

    The SharePoint connectors for the GSA are free and even code with source code. Why doesn’t Google charge for the connectors too? The more document repositories are connected to a GSA, the faster the customer will exceed the GSAs service capacity and buy another GSA.

• Copy-protection – As with the SaaS software distribution option discussed in part 3, copy-protection is no longer needed for the web parts or other components deployed to the customer’s SharePoint farm, as these components are just the service client and should be freely distributable.
   
  However, unlike the SaaS option, the LSaaS service instance you are deploying to the customer’s site does need to be copy protected. The best way to achieve this is to create a service deployment model that ensures that only your service is running on a given operating system instance. That way you can write management code that ensures that everything on the operating system instance, including the operating system components, conforms to a valid instance of you service. Black Blade, Google, and other vendors accomplish this copy protection by distributing their service instances as server hardware appliances.
   
• Level of effort – As with the SaaS software distribution option discussed in part 3, the level of effort for actually doing the licensing and copy protection is fairly low. However, architecting or re-architecting an application to use a service model can be high, especially if a high percentage of the application’s codebase makes direct calls into the SharePoint object model. There is also additional effort involved beyond that which was required for a hosted service in creating an administration and management interface for your service instances. While you can get away with running direct SQL queries and editing raw XML files to configure your hosted service, I would strongly advise creating a more end-user friendly administration experience for the LSaaS service instances you deploy to customer sites. If you are going the appliance route for your LSaaS service instances, you will need to become familiar with shell scripting, writing unmanaged (C/C++) code, and WMI.

Which option is best?

It depends. You weren’t expecting a more definitive answer, were you 🙂 Let me elaborate a bit. If you are just getting started with a product idea, have a product that is mostly user interface, or have limited resources to implement licensing and copy-protection components, I would suggest starting with option 1 (adding licensing and copy protection to the installer only), discussed in part 2 of this series. Once you have a product that is generating some income and you have some more resources to devote to implementing licensing and copy-protection, look at option 2 (adding licensing and copy protection to the installer and the application assemblies), discussed in part 2.

If you have some serious resources you can devote to implementing or revamping your product (say 3-6+ moths worth) and your product provides value through more than just a nice user interface, i.e. the product has a service layer, you will be able to look at option 3 (delivering the product using a SaaS model), discussed in part 3 or option 4 (delivering the product using a LSaaS model), discussed above. Although option 4 has a higher level of effort than option 3, both options require roughly the same magnitude of effort to implement. The key question to ask to determine to which service model (SaaS or LSaaS) you should use to deliver your product is: Where does the bulk of the data the service needs to process reside, at the customer’s site or on the Internet? By that I mean which location has the most data, measured in bytes, that the service needs to act upon, the client’s site or the Internet?

If the bulk of the data, again measured in bytes, resides on the Internet, then you can easily use a SaaS model (option 3) for delivering your software. If the bulk of the data the service needs resides in the customer’s site, then you should use an LSaaS model (option 4) to deploy your service. This is not just an academic exercise. I went through this decision process for each of the products we sell at Black Blade Associates.

Conclusion

This concludes my “Getting paid for your SharePoint software” series. My goal in writing this series was to encourage more developers to start thinking about getting real returns on their SharePoint expertise by monetizing their SharePoint software. A platform like SharePoint can only achieve true success if customers can procure additional platform capability as supported products, not just consulting services. With the impending release of SharePoint 2010, this is a great time to start developing sellable software products for the SharePoint platform.