Table of contents

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

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.

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.

The unwritten assumption in part 2 was that all of the software that makes up your product is installed on the customer’s SharePoint farm. In fact, this is probably the most common model for distributing new SharePoint capabilities, but it does come with some challenges from a licensing and copy-protection perspective. Lets take a look at some alternatives…

Option 3: Give away the web parts for free

Wait! Don’t post that angry comment yet. While many people hear “SharePoint application”, they think of web parts. But there is certainly a whole lot more to SharePoint than just web parts. In fact there is a whole lot more to SharePoint applications than just user interface. There is data and processing of the data. Typically, while the data is stored in SharePoint as lists and libraries, and the user interface resides in SharePoint as web parts, the processing of the data can be neatly abstracted from and need not have any reliance on SharePoint at all.

For example… lets say you wanted to build a “web part” that would allow the user to select a Word document in SharePoint and convert that document to a PDF file. You could do that all within the web part (I wouldn’t recommend that), but then you are limited to the licensing and copy-protection options discussed in part 2 of this series. But what if you were to de-couple the user interface (the web part) and data (the Word document) from the processing (converting a Word document into a PDF file)?

You could allow a customer’s user to select a Word document in the customer’s SharePoint farm to convert using your web part, and once the user selected the file, your web part could send that file off to your Web Service running out on the Internet for conversion to a PDF file. Once the conversion is complete, the web service could upload the file back to the customer’s SharePoint farm.

Not only is this is a different application architecture (SOA) but also a different business model (cloud / utility computing). This option completely negates the requirement to license and copy-protect the code running on the customer’s SharePoint farm. The service the web part is accessing is licensed and copy-protected.

• Licensing – Licensing is much easier here as the code running on the customer’s SharePoint farm is freely distributable. The service usage is what is licensed. There are many options available including:
  • Per-use licensing
  • Flat monthly / yearly subscription
  • Base monthly / yearly subscription with additional usage licensing
  • Data size-based usage
  • Service resource utilization-based usage
  • etc, etc, etc
    The only licensing model that is a bit of a challenge to enforce is a per-user model, though that can be done with some work.
• Copy protection –  Copy-protection is no longer needed for the web parts as they are freely distributable. Nor is copy-protection needed for your Internet service that the web parts access as you are not distributing the service. What you do have to “copy-protect” or validate is the identity of the invoker of the web service, since the invocation of the web service is ultimately tied to billing.
  • Username and password: This can be done easily using a username and password that the customer uses when they configure the web parts. It is in the customer’s best interest not to distribute that username and password because that will incur more charges to their account. The downside here is that you have to maintain a secure identity repository that is tied to your billing system.
  • Client certificate: Issuing a client certificate to each of the customer’s SharePoint web front end servers is a much more secure way to validate the identity of the server invoking the web service. You can program your web parts edit menu to have an option for an administrator to request a client certificate from your certification authority. If your certification authority runs on Windows Server 2008 R2, you can leverage Windows Server’s out of the box web service for requesting certificates.
• Level of effort – The question of level of effort is a trick question for this option. 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. Depending on the current application codebase, the level of effort to re-architect an application using a SOA could be as high or higher than the level of effort for designing the original application.

  That begs the question: Is it worth it? This is obviously depends on the application or capability being developed, but if your application can support this model, the answer is YES, it is definitely worth at least investigating delivering the application as a secure service with web parts freely distributed to customers and prospects. In addition to ease of licensing and copy-protecting the application you gain other benefits:

  • Support: Ongoing support is one of the biggest hidden costs in application sales. Once an application baseline has been tested and gone through QA, the most common cause for new bug discoveries is platform configuration variations of the platform on which the application is being installed. We’ve all seen too often how an operating system update can “break” software that had previously been working.

    If 100% of your application is installed on the customer’s SharePoint farm, then 100% of your application code may break as operating system updates and other applications are installed onto the customer’s SharePoint farm. With a services architecture you can greatly reduce the impact of these changes to your application by simply not having nearly as much code deployed to the customer’s farm.

  • Maintainability: Maintaining an application is closely related to the support costs discussed earlier. As with providing support, great percentage of maintenance costs and complexity in an application result from adding code to allow the application to deal with variations in the customers’ platforms on which the application is installed.

    How does a services application architecture help minimize the impacts of customer platform variations? By simply reducing the amount of code deployed to the customers’ platforms, you reduce the amount of code that needs to account for platform variations. The codebase for your hosted service does not need to account for platform variations because you control your service’s platform.

    Here is just a small list of customer platform variations to consider:

    • WSS V3 / V4, MOSS 2007 / SharePoint Server 2010
    • Windows Server 2003 / 2003 R2 / 2008 / 2008 R2 / Service Pack 1/ Service Pack 2, etc…
    • Windows Server x86 / x64. By the way, if you think this variation doesn’t matter, read my other post on things that don’t work on x64 platforms.
    • SharePoint authentication model: NTLM / Kerberos / FBA / Smartcard, etc…

All services all the time?
On first thought, the services model really does sound great. On second thought though, we can start to see some potential issues with this approach as well.

The first issue is bandwidth. While your customers may have a fast local area network (LAN), say 1000 mbps, they probably have only a small fraction of that bandwidth available on their wide area network (WAN), probably 10 mbps. That’s only 1 percent (or less) of LAN bandwidth available over the WAN. The WAN of course is what is used to connect to the Internet, where your service is hosted. We can quickly see that while occasionally processing documents by sending them to a hosted service over the WAN may be feasible, processing even moderate amounts of data can quickly consume the scarce WAN bandwidth.

The second issue is security. From your customer’s perspective, they are using your service, along with potentially a large number of your other customers. What guarantee do they have that you have taken adequate measures to prevent one of your other customers from seeing their data? This is a big concern in multi-tenant systems, regardless of where the systems are hosted. This risk is in addition to the general risk of exposing your customers’ data to the hackers and viruses prolific on the Internet.

Another potential issue is one of user context or single sign on (SSO). This issue is tangentially related to the security issue mentioned earlier. In essence, if your service needs to do work in the context of the user who initiated the processing, it is much more difficult to do this when the service doing the work (your Internet hosted service) is not connected to the same authentication source as the system that received the initial user request, I.e. your customer’s SharePoint farm.

This list of issues is by no means exhaustive, but it does show some of the most common issues with hosted services or cloud computing application architectures.

To be continued in part 4…

Check back soon for the fourth article in the series. In part 4 of this series, I will show how modify a traditional services application architecture can allow us to gain the benefits of services in licensing and copy-protection while avoiding the potential issues with the architecture.