Over nine random days the past couple of weeks (SP SIN just reached build 9, which is the RTM build for version 1.2) I’ve been tinkering with SP SIN, a new framework for injecting stuff into SharePoint pages. Which is fine, I’m sure you can read my other blog posts on the topic if you haven’t been paying attention.
One thing that I announced I’m working on is an app store for SP SIN. Initially, it was only intended to allow people to add configuration packs to SP SIN, but then I thought that this might be interesting for other types of solutions too. In fact, why not create a full app store for deploying any type of solution?
SharePoint 2013 introduces the concept of a marketplace, but you may not know that there’s actually been a framework in place for a marketplace in SharePoint 2010 too. The problem is that nobody uses it, and its only contents is a sample package from Office.com, which isn’t useful at all.
So, SharePoint 2013, right? We can now finally get a marketplace where developers can add stuff and you can buy stuff, and everyone should be satisfied.
Here’s why I think the SharePoint Store isn’t going to be green grass and champagne all the way.
SharePoint Store Caveats
Let’s say that you’re a developer building wonderful jQuery-based solutions in SharePoint. Let’s say you’ve built this cool new widget, for example a fancy fly-out menu, a neat way to filter or sort a library, a slide show, something like that. You may have spent a couple of hours on it, nothing you’d like to build a business around, but still something that would be useful not only to yourself but to others.
Let’s say you want to add that to the Microsoft SharePoint 2013 Store. In order to do so, you need to register for an account, which is reasonable, I guess, but then the process of getting your couple-of-hours project listed starts.
Figures for how long this process takes range from ‘just a couple of weeks’ to ‘upwards of two months’ before your cool fly-out menu that would potentially make thousands of SharePoint sites easier to navigate is available. During that time, you’ll need to interact with the process on several occasions, even if your app is as simple and free as copy-pasting a script from a page.
Microsoft wants you to be committed to your App; if you’re just making something useful that you have no plans to support, earn money from, or build a business around, well, you’re still required to go through the hassle.
I can understand this. Quality before quantity. Microsoft wants their App store to be a place where you find only content that has gone through an extensive process to ensure quality. This is great for more extensive Apps and great for consumer security, but not so much for simpler solutions and for those that want more flexibility at the possible cost of the pre-validated solutions in the SharePoint Store.
Another obvious drawback of the SharePoint Store is that it only supports SP2013 Apps. There is no support for SP2007 or SP2010, and there is no support for any other application delivery model, like farm solutions or sandbox solutions. Again, this is Microsoft’s choice, they obviously want people over on the new model and the new version of SharePoint.
The jury is still out on whether the new App model is a great thing, but regardless of whether the market will accept Apps, the undeniable fact is that Apps provide only a subset of functionality. By design, Apps can only do certain things, and this is done to improve security and stability of SharePoint. If you want more power, like what you need to deploy farm solutions, then the SharePoint Store will not offer you any options.
However, this is a problem for vendors, who for the next couple of years at least will still have to support clients on earlier versions of SharePoint. That means that if ACME Corp wants to have both SP2010 and SP2013 clients that want Apps, they need to build and maintain two separate solutions, increasing the development cost, which again trickles down to a higher price for the clients.
WordPress Got It Right!
On reason why WordPress is successful is its abundance of plugins, easily accessible at the click of a few buttons. If you don’t like the way something works in WordPress out-of-the-box, you can bet a fair chunk of money that there will be a plugin to fix your issue. In fact, you’re far more likely to find several plugins solving your problem and you’ll spend time finding out which one solves your problem best. That’s a good thing for consumers because it means they have a choice. If solution A doesn’t work the way you want, then you can pick solution B or solution C instead.
Previously, Microsoft has been explicitly discouraging apps that are similar to existing apps in their various attempts at marketplaces. I haven’t seen any explicit mention of such a limitation for the SharePoint Store (except they say you cannot duplicate your own App), but because the App must go through a Microsoft approval process, they may introduce such a requirement at any time.
Further, WordPress plugins are free, always. That is, the plugins in the WordPress plugin repository are free. A plugin may certainly sell you additional services and there are external sites that sell commercial plugins too, but the built-in stuff is free.
Getting plugins for WordPress is also dirt simple. Search for what you want, click Install, and you’re good to go within seconds. There’s no limitations on the code you can deploy, and the code runs as securely or insecurely as you’ve set up your environment.
One drawback of the WordPress plugin ‘store’ is that there’s a lot of junk there. In fact, finding the really good plugins take time.
Of course, from a vendor’s perspective, because everything in the WordPress store is free, there’s no built-in business model. That may or may not be a problem; after all, if vendors do see the SharePoint Store as a marketing tool in any case, they may not see the big revenue from such a marketplace in any case. Also, regardless of the free model in the WordPress store, there seems to be a thriving community of commercial plugin vendors, many of which have trial or feature limited versions of their commercial offerings available for free.
What Do You Want?
As I mentioned, I’m working on an App store to run on top of the SP SIN framework. I want to make that App store, dubbed the SIN Store, much closer to the WordPress model than the SharePoint Store model. I want to share my ideas with the community and ask for your feedback on the idea, so please, either email me, comment below, or contact me in any other way with your thoughts.
Here are my ideas. None of them are set in stone, so if something doesn’t feel right or needs to change, then I’ll change it.
- The SIN Store will have an open submission policy, just like WordPress. I’ll ask application authors to register, but that’s merely to enable them to maintain their apps. If you can upload your solution file and fill out a simple form, you can publish your solutions through the SIN Store, whether they are farm, sandbox, or App solutions.
- I will (and already do) support all types of SharePoint applications, not just SharePoint 2013 Apps, and I will (and already do) support all versions of SharePoint. I’ve already demonstrated the SIN Store running on SharePoint 2007, and I’ve shown to several people how the SIN Store now supports sandbox solutions in SharePoint 2010 as well.
- The SIN Store is as extensible and customizable as SP SIN is, meaning that vendors or developers can modify it to work any way they want, including adding payment and licensing options. I don’t add any licensing mechanisms out-of-the-box because I know that vendors tend to be rather particular about how they enforce their licensing. However, as a proof of concept for myself, I’ve tested a model that sells a license code through an online payment provider that in turn is installed in SharePoint and grants access to an application. There’s still too much to figure out on that part, though, so no video of just that yet.
- The repository of available apps in the SIN Store is modifiable, so companies can easily add their own app catalog, just like you can in SharePoint 2013 (although, again, for all versions of SharePoint and all types of applications). A usage example may be for a hosting provider to add their own catalog of Apps that they can and will support for their hosted clients. It can also be used to block the default SIN Store repository if you don’t like the open submission policy or are freaked out by the possibility of adding solutions that haven’t gone through a rigorous approval process.
(I’ve also demonstrated this to people in one-on-one sessions. )
- The installation process is also extensible so that if future versions of SharePoint introduces yet another model for app development and deployment, then the SIN Store will support that too. I’ve already shown this extensibility in how I support sandbox solution installation and I have the code ready to support SP2013 Apps as well. Even better, it enables users (and developers) to modify how they install their apps, for example to enforce licensing purchases or management (and it’s actually easy too).
There are some thing that I want to change from how WordPress does their plugin store as well. It can be extremely difficult to find the right type of plugin and the only option you have is really to search in the store, hoping that the keywords you use are the right ones. The SIN Store will have a different navigation model that allows you to categorize your applications better. There’s already support for tagging and categorization, and the SIN Store also categorizes content based on platform capabilities (so you don’t see sandbox solutions in SharePoint 2007, for example).
Further, I want to make it easy for developers to request capabilities. In other words, your App may utilize managed metadata which means you need to have a version of SharePoint that supports that, and have that service available. You can, of course, also limit your application to work just on a certain version of SharePoint and not have it appear in the store if that version isn’t available.
Finally, it needs to be incredibly easy for those users who care only about getting the functionality in place, but also flexible enough for more demanding scenarios like scheduled and targeted deployments. There are already quick-install buttons for all application types and a pending “Configure Installation” button that right now does nothing but is intended to allow users to determine exactly when, where, and how the app installs.
So, based on this, what are your thoughts? Will this be too much and too far? Is there a need for a competing marketplace? Are there features and capabilities I haven’t thought of? If you’re a developer, would you put your app in such a marketplace?
Let me know your thoughts, rants, ideas, and questions…
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!