Let’s get the easy part out of the way, the specific case of Nintex…
- Microsoft Office SharePoint Server 2007 shipped in November 2006. Work on what we now call Microsoft SharePoint Server 2010 began months before that date. I didn’t leave Microsoft until the end of May 2008.
- Make no mistake: the day I left Microsoft, I put up a “Chinese wall” around part of my own head, and I continue to regard my ex-employee NDA as a sacred trust. But ask yourself: would Fitz join a company whose products would be rendered obsolete by what he knew was being planned for “Office 14”? (Hint: no.)
And now let’s address the general issue, which applies to many, many ISVs…
- Microsoft develops software in three-year cycles. Not every group at Microsoft follows this rule as closely, but the Office group (which develops all SharePoint technology) certainly does. It’s for several reasons, the more interesting of which are:
- It appears to be the sweet spot; wait longer and the product gets stale, don’t wait enough and people are driven crazy with upgrade chores.
- It times nicely to Software Assurance (SA) agreements, which are signed for three-year cycles. SA is essentially upgrade insurance. Pay a certain amount of money over a three-year period and you get any new releases that come out during that time.
- There’s only so much that can be done by a finite number of people in three years. You can’t increase the number of people without the coordination costs going through the roof. That leaves limiting the feature set.
- To add to the above point, SharePoint technology has so many interactions with so many other Microsoft products – all of which usually ship at the same time – that they’re extra constrained by how much they can accomplish. The test matrix alone is staggering, and at a point much sooner than most people think, testability determines whether something is kept or cut (or, very rarely, added).
The above argument pretty much ensures that the next version of anything you buy will be nicer, better, probably (in this case, I suspect definitely) worth the money and time spent upgrading, but it won’t be the release to end all releases.
There will be a gap between what you really want and what’s in the box.
Toward this point, Microsoft (at least the product teams in Redmond) all but depends on the partner ecosystem to plug feature gaps or create specific productized solutions. Systematic procedures and practices are in place to help ISVs do exactly this.
In fact, when faced with enough resources to either add a user-facing feature or improve the platform so ISV products and custom development efforts can build such a feature, the second approach usually wins. Not always, but most of the time. Here’s why:
- It’s a bigger bang for the buck. If they enhance the platform, many solutions can be offered that leverage the new functionality. From different vendors. Taking different approaches. One of which will probably address your needs.
- Many people can build features or solutions. Only Microsoft can build platform enhancements. If ISVs attempt to do that, they’re basically hacking the back-end product – not the safest option in the world.
So, what makes for a decent ISV versus a not-so-decent one? One topic at at a time — give me about 24 hours or fewer to post about that.