A new Office Store has been announced by Microsoft which opens up a wider way to make money from coding for Office, but at the price of throwing away all the useful code from the last 15 years - sound familiar?

The Office team has written in some detail on the Office Next blog about how developers need to change the way they work in Office to make use of these new money-making opportunities.

The short version is that while VBA, macros and add-ins all still work in Office 2013 and SharePoint 2013, the way forward is based on Web standards.

As Rolando Jimenez Salgado puts it in the Apps for Office and SharePoint blog:

If you can create a webpage, you can create an app for Office.

He points out that from a development perspective, an app for Office is essentially a web page integrated into Office as custom content, very similar to how iFrames integrate with other pages on the web.

The web page needs to interact with Office content by including a standard script tag referencing Microsoft’s Office JavaScript library, so in its most basic form, an app for Office is a webpage plus an xml manifest file:

Brian Jones, Principal Group Program Manager for the Office Solutions Framework team said in the Office Next blog that in the new Office and SharePoint, Microsoft is introducing a new cloud app using web standards such as HTML5 and CSS3.

The idea is that the new apps are simply web applications that are inserted into Office documents or SharePoint sites. Apps for Office could be inserted as part of templates, or as task panes into documents.

In Outlook, they’d be activated automatically within mails or appointments when applicable. In SharePoint 2013, everything is an app. They’ll be able to extend the SharePoint Ribbon and menus, be embedded as part of a site, or be a full web page, as demonstrated in this short video:

Apps have to run in a separate, isolated process so that if the app crashes, Office will continue without being affected. Apps won’t be allowed to overwrite the Office UI, or to block events.

While this does get around the problem of multiple add-ins each blocking events and altering the ribbon, it does block areas that have proved useful where Office as supplied by Microsoft hasn’t behaved the way users wanted or developers needed. Apps will only run if a user inserts them into a document, or opens a document that already contains an app.

In Outlook, apps can advertise themselves based on the content of the mail, but the app will only run if the user clicks on it, and will stop running if you click on another app or close the one that’s open. In SharePoint, you pick what site you want to install the app, and it will only run in the context of that site.

When a potential customer receives a document containing an app and they open the document they will have the option of activating the app, and in the case of a paid app they can either pay for it or run it in trial mode. Apps shouldn’t be thought of as an extension of the Office application itself, but instead as an extension of the document content.

Customers will also be able to find apps from the Office Store, and add them to their “my apps” list. When someone goes to the store and provides their Microsoft account, any app they’ve installed will be associated with their account and those apps will be available anywhere they run Office. Nothing is installed on the local machine. It’s all registered on the server and all your apps will roam with you.

Of course all of this is just a catchup with Google. It's web based office applications are already here and working. You can create Google apps using nothing but JavaScript (and a little HTML if you want).  The App Script infrastructure is readly in place and works with all of Google's services and many external services. Microsoft still has a long way to go to equal Google's offering.

Behind the scenes, the way this works is that when someone installs an app, they actually install a pointer to the location where the app is actually stored. This could be in Windows Azure, Amazon, or any accessible cloud site. Organizations will also be able to set up a private “App Catalog“ to distribute and manage business critical apps internally. Money from apps sold in the Office Store will be split 80 per cent to the developer, 20 per cent to Microsoft.

There are times when I think a sideline in punchbags with a suitable Microsoft image on would be a good seller, and this is one of those times. Microsoft’s ‘big company with lots of money’ world view shows through very clearly. It is so cushioned from its actions that it can make a major change and still be profitable, so it assumes that developers are equally cushioned.

Essentially, Microsoft is saying 'throw away everything you've worked on for the last 15 years, we've thought of a better way' and not offering any route for making money through the app store for add-ins.

Just ignoring the huge numbers of VBA add-ins and code undoubtedly makes life easier for app management, but it’s hardly supporting the developer ecosystem, is it?