SharePoint is one of the fastest-growing products in the history of Microsoft. It is a lot of things to a lot of people, and an entire industry has grown up around SharePoint because of its success. Its future, however, is less rosy. What's more, Microsoft's design decisions also make this future murky.

Let's take a look at why SharePoint's roadmap should concern CIOs.

Multiple personalities frustrate IT managers and users

SharePoint has multiple personalities. There are, in effect, two versions of SharePoint that you, as IT management, need to be aware of. There's the online version, called SharePoint Online and Office 365, and there's traditional on-premises version called SharePoint 2013, which you have come to know and love over the past few years.

You may have a reason to be interested in both versions. You want the convenience and simplicity of paying a low monthly fee for someone else to take on the hassle and inconvenience of deploying SharePoint for your organisation, while you may want to have a few document libraries and sites remain in your own data centers under your control if, say, they host sensitive files. You might also want to control search a little bit more and configure a hybrid search environment. Whatever your reasons, there's a place in your environment to plan for both versions.

Consider what this dual edition means for end users, though. Microsoft has publicly stated that its cloud services are where new features and functionality are first rolled out. These capabilities may eventually make their way down to the on-premises server versions but, traditionally, SharePoint server releases come every three to four years.

Even on Microsoft's new rapid-release cadence, the company still hasn't yet proven it can deliver high quality platform server editions any faster than it has in the past. Your users may have quite an uneven experience, with some features deployed in the Office 365 and SharePoint Online environments - and even having been there for years - before you have a chance to deploy them in your own data centre.

Then there's the lack of control over new features, or even changes to the interface or to existing features, when they are made by Microsoft in the SharePoint Online environment. You basically have to accept the fact the cloud service is the testing ground. In exchange for giving up the headaches and paying that low monthly fee, you give up having the ability to say no to changes. This includes not just changing a control here, the URL of a page over there, or deprecating a little-known advanced feature without much notice.

The Yammer rollout is a prime example. Once Microsoft bought Yammer in 2011, it essentially decided that Yammer was the future of SharePoint social and, in effect, dismissed anyone's investments in the in-the-box social features that existed in SharePoint 2010.

Yammer has already been named the preferred replacement for the News Feed feature on SharePoint Online and Office 365 tenants - but as of this writing, there's no concrete roadmap for when Yammer can be integrated with on-premises SharePoint, or how you might go about doing that integration once it's possible.

In a hybrid environment, therefore, you have one set of social capabilities on one collection of sites, and still another - probably preferred - set of capabilities on another site. All this for a feature designed to bring your employees together. When you step back and consider the absurdity of that situation, you begin to see some of SharePoint's challenges as it moves forward.

SharePoint app store model hasn't succeeded

The SharePoint application model represents another bit of concern. Perhaps emboldened by the success of the Google and Apple app stores, or perhaps just throwing caution to the wind to the burgeoning SharePoint developer market, Microsoft decided to bring the app model to SharePoint.

Developers could write apps either for internal use for their own companies or for public consumption, and SharePoint 2013 would be able to securely run them in their own little worlds. There's even a model for the different types of apps you could have: You can have full-page apps, extension apps or app parts, which are essentially the old web parts most of us in the SharePoint community have come to hate).

It seems like a great idea, of course. Many companies were developing solutions to run on SharePoint already, and the product itself had developed in a full-fledged platform, à la ASP.NET, running custom code that delivered all manner of solutions for different organisations. Being able to select both internal and third-party apps from a central console, complete any payment transactions and get that functionality ready to roll would have been a pretty big leap forward in the SharePoint space.

By all accounts, though, the app model has not yet taken off, even a year after the initial release of SharePoint 2013. In my opinion, there are two primary reasons for this:

They're in the wrong language. SharePoint apps are to be written in HTML and JavaScript, the languages du jour of the web. But Windows developers and SharePoint developers know C#. They know ASP.NET. They don't care to step down in many ways to inferior web languages simply to run within a Microsoft platform. After all, C# and the various .NET apparatus technologies have been the bread and butter of Microsoft's development model for some time. Many developers wonder why Microsoft would now push that investment to the side.

There's no consistency to the guidance given to developers. In the SharePoint 2010 era, Microsoft convinced everyone to write to a sandbox model. This meant, essentially, that SharePoint solutions ran within a restricted environment that limited the bad things that could happen when code ran within a SharePoint deployment. Much attention was given to educating the SharePoint consultant and developer that the sandbox model was where they wanted to be; as a result of this heavy attention, these groups really invested in training and developing for that model.

The SharePoint 2013 app model is entirely different than the sandbox model, using an app engine that, to many developers, doesn't seem to add anything to the solution set. To pour salt in the wound, much of this custom code isn't able to be deployed into SharePoint Online and Office 365. More training, more relearning, more disposing of old skills - and to what end exactly?

The future - SharePoint 'bears close watching'

When your product has multiple personalities, you have a new model that is anything but successful at this point, your model requires developers to code in languages with which they are not familiar, and your guidance about investing in certain development models changes drastically from one release to another, it's not hard to understand why your future is challenging.

Overall, SharePoint is a great product, but mixed messaging and moving targets make it hard for savvy CIOs to invest in a platform. At this point, the situation bears close watching.