In Memorandum: Georg Oscar Furuknap

Do what thou wilt shall be the whole of the law!

My father, Georg Oscar Furuknap, d.o.b. November 22, 1944, died this morning, on June 30, 2014. May he be granted the accomplishment of his will.

I didn’t know my father recently and we haven’t spoken in more than a decade. We barely spent time together for a number of reasons. Those reasons are irrelevant today and shall forever be forgotten.

Today, I celebrate the passing of my father. He lived his life as he desired, bearing the consequences of his choices, whether good or bad. I cannot imagine he really regretted anything he did.

I also cannot imagine he wanted me or anyone to grieve his passing so instead I choose to celebrate that he has accomplished everything he ever will. I will drink and be merry in his name and know that if there is an afterlife, he will make hell a bit better or heaven a bit worse. Or vice versa.

Here’s to Georg Oscar Furuknap: Skål!

Love is the law, love under will.

To those contemplating offering condolences, please re-read the above text. If you do not understand that text, spare me your selfishness and shut up. 

Norwegian translation:

Gjør hva du vil skal være hele loven!

Min far, Georg Oscar Furuknap, f. 11. november, 2944, døde i dag morges, den 30. juni 2014. Måtte han sjenkes fullførelsen av hans vilje.

Jeg kjente ikke min far i det siste og vi har ikke snakket på over et tiår. Vi brukte knapt tid sammen av forskjellige grunner. De grunnene er ikke viktige i dag og skal for alltid glemmes.

I dag feirer jeg min fars bortgang. Han levde det livet han ønsket og tok konsekvensene av sine valg, enten de var gode eller dårlige. Jeg kan ikke forestille meg at han noen gang angret noe han gjorde.

Jeg kan heller ikke forestille meg at han ønsket at jeg eller noen skulle sørge over hans bortgang, så i stedet velger jeg å feire at han har oppnådd alt han kommer til å oppnå. Jeg skal drikke og være glad i hans navn og jeg vet at om det er et liv etter døden så kommer han til å gjøre helvete litt bedre eller himmelen litt verre. Eller visa versa.

Til Georg Oscar Furuknap: Skål!

Kjærlighet er loven, kjærlighet under vilje.

To those contemplating offering condolences, please re-read the above text. If you do not understand that text, spare me your selfishness and shut up.

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!

Pin It

SharePoint 2013 App Model – The Jury is Back

A few months ago, I stated that I was still on the fence on the SharePoint 2013 App model and that I needed to see more of it to determine whether it is useful. I followed this up with a post titled SharePoint 2013 App Model Solves Non-Problems Only? that have since sparked some debate.

I’m happy to report that the jury is now back and is ready to pass a verdict.

I, the Jury, Find the Defendant Useless!

Let me skip right to the conclusion so you lazy people can just move on. The SharePoint 2013 App model is useless. It isn’t innovative,  it doesn’t offer anything you cannot already do, and its main purpose is as a marketing ploy from Microsoft.

From a technical perspective, I find the App model to be severely lacking even in the most basic functionality. From a user perspective, it is confusing and disappointing. From a developer perspective, it is boring and offers no incentives to adoption.

Finally, and this should interest Microsoft immensely, it is undermining the trust in SharePoint and Microsoft as a serious contender for enterprise functionality.

Now that you’ve read the conclusion, you can sod off and start polluting the interwebs with counter-arguments to demonstrate your lack of understanding.

For those that wish to increase your understanding, read on and I’ll elaborate on why and how I’ve reached this conclusion.

Oh, and you should probably also read the first article on SharePoint 2013 non-problems because it answers some additional points that were clear way back then.

Lack of Innovation

The App model offers a completely new way to build functionality on top of your SharePoint data. Or does it?

The basic premise is that from now on, you should build your Apps outside the SharePoint farm and just call into SharePoint using web services.

But this isn’t really new, is it? For years, those that wish to build functionality this way has been able to do so through libraries like SPServices. Marc Anderson has been a champion of building non-managed code solutions for SharePoint longer than most people have known how to spell SharePoint.

The ‘newness’ has also been argued to be in the vastly expanded functionality that the web services offer and that there are now Microsoft libraries to communicate with these services. Again, this is nothing new, except that the author of the libraries is now Microsoft rather than Marc Anderson.

As for the expanded functionality, this has always been available to anyone who needed that functionality. In fact, even after SharePoint 2013’s release, Microsoft themselves advised customers on how customers could extend the web services with functionality that isn’t included in the App model libraries.

In short, there’s nothing innovative about the model. Everything has been possible all along.

Technical Shortcomings

Even if one were to accept the argument that the concept behind the App model, of putting the calling HTML and JavaScript files somewhere else, is valid, the App model lacks plenty of functionality that is required to build anything but the simplest of solutions.

A typical and recently mitigated example is the lack of ability to create a site collection through the App model. That’s right, up until just recently, there was no way to create a site collection through the App model. It was mitigated on Office365 some time ago, but on-premises clients were relegated to extending the web services on their own. If, for example, you wanted an App to create unique site collections for various projects or teams, which is a pretty common pattern, well, you couldn’t do that.

Note: I’d also like to take this opportunity to point out that this shortcoming wasn’t discovered for almost two years, which should say something about the adoption.

This isn’t the only example either, and a lot of the functionality of SharePoint isn’t and can’t be made available through the App model at all. Examples if this are delegate controls, event receivers, and a range of layout options that cannot be accomplished because of fundamental shortcomings in how Apps work.

So, solutions have to rely on extending the web services themselves. That’s been possible for over a decade already. So what if there’s a new URL you can use to retrieve the data through REST; if you needed that, you could have done so years ago and in some cases you’re still being asked to do so.

Developer Incentives

A key selling point for the App model is that it makes SharePoint development available to anyone who knows how to use HTML and JavaScript. Microsoft has even said that it now has millions of additional developers because anyone with HTML+JS skills is now a SharePoint developer.

The premise of this argument is that through HTML and JavaScript, developers can now access SharePoint data and develop solutions that use SharePoint simply as a data service.

The problem with this is that the App model with its limitations offer very little to incentivize developers to use the platform. At its core, the App model gives you access to SharePoint data, which could have been cool, except that as a data engine for the web, SharePoint isn’t competing.

Note: If you want to look at the competition on data engines for the web, look at Amazon’s range of data services in AWS or even at Azure; all of these offer data engines that far outperform and out-feature SharePoint.

HTML and JavaScript developers look at what features a service provides when deciding where to put their learning and development efforts. That means that SharePoint needs to compete with every other commodity data service.

And it does. Except that the functionality that makes SharePoint competitive such as workflows, delegate controls, master pages, event receivers, and so on still requires farm solutions. That means that to a developer, you either use SharePoint as is, which means it has to compete without any of its unique features, or you still need to learn farm development.

In short, SharePoint as a data service isn’t viable in face of the competition.

User Disappointment

Another key selling point is how easy it would be for users to now implement new functionality in SharePoint. They simply head over to the App store and download the awesome Apps that will improve their work life with a click of a few buttons.

The problem here is that there’s so much you cannot do, many of them high on the list of things users want, that it becomes a disappointment faster than you can convince anyone of the subtle benefits.

Want to create site collections for your teams to manage themselves? Sorry, can’t do that (well, now you can, but it’s taken almost two years).

Want to chance the look and feel of SharePoint (and isn’t that always high on the list)? Sorry, can’t do that.

Want to implement simple functionality to fix things like missing Title fields in documents? Sorry, can’t do that.

I’ve reviewed several business cases for functionality and solutions to be built on top of SharePoint and so far, I’ve always had to either say “Sorry, the App model won’t work” or ask the client to change their requirements because the technology can’t accomplish what’s required. I’ve always been able to say “Well, if you’re OK with using Farm solutions, it can work”.

Users see that what they want to accomplish can’t be done more often than they see that they can get stuff done easily.

Lack of Trust

I’ll probably come back to this point in a separate post later, but Microsoft has painted itself into a corner when it comes to building customer trust.

If you look at the history of the recommended SharePoint solution models, you’ll realize that for every version of SharePoint, Microsoft has changed its recommendation. Microsoft shifts their recommendations so often that it is impossible for organizations to keep up. Organizations and developers put their money and time into a certain and recommended method only to have that method ridiculed or deprecated a few years later.

So, Microsoft, if they were to change their recommendation again for vNext (aka SharePoint 2016), would lose any trace of trust they have. They cannot simply abandon the App model, so they have to stick with it, even if they themselves realize it’s sometimes ridiculous and lacking.

That means they must keep working on getting the App framework to catch up with Farm solutions and that further stifles innovation. They cannot create awesome new functionality that harnesses the power of SharePoint fully because they still haven’t gotten most of the basic functionality to work. And they cannot abandon it because it would kill every ounce of trust they still have in SharePoint as a development platform.

You Are Sentenced to Oblivion

With all these problems with the SharePoint 2013 App model, I’m sorry to say that I don’t really see a future for it at all. Not just that, but the App model is holding back the innovation of SharePoint as a platform; the very thing that made SharePoint so awesome in 2007.

Unfortunately, Microsoft can’t abandon it either; they’ve put too much clout into it. Their entire development story for SharePoint 2013 hinges on the App model, and it’s not telling the story that developers want to hear and it certainly doesn’t tell the story that users want to hear.

It doesn’t matter whether the administrators love not having to deal with farm solutions anymore because, long term, the business solution doesn’t involve SharePoint at all.


Pin It

On Innovation and How I Wrote SharePoint

After my somewhat public denunciation of SharePoint and prediction about its imminent demise, I’ve had quite a number of talks with people about my passion for SharePoint. Why am I (or was I) so intrigued with SharePoint and what has changed now?

It’s simple really. I wrote it.

You’re probably bright enough that you understand that there’s a longer story behind that, but that’s not really the point of this post. I’m telling you because you need to understand where I come from when I talk about how the innovation in SharePoint has died.

Let me start at the beginning.

You Wrote SharePoint? Yeah, Right!

Well, I didn’t write SharePoint as such; the fine people at Microsoft did that.  What I did write, along with a good friend and brilliant developer named Vegard Berget, was a publishing system called NB2 Publish, that did much of what SharePoint does today.

NB2 Publish was a platform for turning data into content of various types (like… types of content or… content types). It had some pretty amazing features that I still haven’t seen in a lot of modern publishing platforms. For example, the platform supported automatic image optimization so that when you uploaded an image from any format (TIF, PCX, TGA, BMP, GIF, whatever) the platform would automatically convert the image to the optimal format. Of course, automatic resizing and stuff like that was included.

NB2 Publish also supported multi-publishing. What that means is that when you decided to publish something (and there were workflows to do so) you could publish the content to any number of different channels. For example, if you want to launch a new product, you need to produce PDF flyers, update a product database, create a new entry in a carousel, send out emails to your mailing list and so on. All of that is based off the same information, so NB2 Publish allowed you to accomplish all those things in a single operation. If I recall correctly, we even supported faxing at the time.

To support all these different types of publishing, there was also a cool dynamic input system that auto-generated forms for input based on what the various channels needed. For example, if you needed your PDF flyer to have a larger product image, you’d simply update the template used to generate the PDF, and Publish would automatically update the input form and give you a file upload box. It would then make that file available across every channel.

You know, like custom field types work in SharePoint. If they did.

Except NB2 Publish was more awesome because it took the reverse approach to the dynamic typing problem in SharePoint. Rather than depending on the user maintaining a correct list of field names and then telling the target that “here’s the information available, if you’re missing something, tough luck”, NB2 Publish would instead ask “What information is required to accomplish this task” and ask the user to provide that. No risk of field corruption; if you screwed up, the user would simply be asked for the additional data rather than the whole system crashing or you having to rewrite your entire database just because you hadn’t planned for that one feature the user requested.

The NB2 part? Well, that was mainly a development framework in which we had built our own scripting language (which we later found out was actually Lisp, or at least a related language). Heck, in later versions, we even had remote support, somewhat similar to web services, so you could call into the publish engine from any programming language that could send text over the wire.

We even had remote scripting support and that didn’t mean what you think it means. Imagine if you can write a program that sends off parts of itself to be executed on another server. Multi-threading would never be the same. Now, every computer connected to the internet, and being able to run NB2, would be one massive computer to which you could send instructions for execution and get results back.

– How many cores did you say you had?

– I don’t know, how many computers are there on the internet?

All in all, it was a pretty awesome product. Sure, it wasn’t nearly as fast and the code base was… Let’s call it interesting for lack of a better word. It lacked a lot of the bells and whistles, but we knew how to do amazing things with the platform and the framework.

And, here’s the kicker: We wrote this in 2000. Yup, years before SharePoint saw the light of day and even before .NET made remote web services a reality, we had all that. We had safe and stable dynamic languages that was so easy to use we trained our secretary to build templates for customers (she was smart, but maybe not computer smart). We had content types, list and document repositories, automatic PDF creation, email alerts, custom field types, workflows… The lot. Plus more.

Now, you’ve never heard about NB2 or NB2 Publish (unless you worked for or were a customer of the company whose name is now tattooed on my left arm) and you’re probably not going to believe any of this. That’s fine, I’m not here to convince you of anything, but if you’re capable of either reading Norwegian or can use Google Translate, you can read a lot more information about NB2 and NB2 Publish at’s repository of

Note: You may also, with some sleuthing, realize we also wrote Google Analytics in 2001. It was called Stics and I’m not giving you more hints.

You’ve never heard of any of this because at the time, we were a very small software shop. In fact, with a few and very valuable exceptions, Vegard and I were the only developers there. That leads me to why I was passionate about SharePoint.

Innovation is Such a Lonely Word

You see, the company, or companies, that owned NB2 and NB2 Publish eventually went bankrupt. They died out. That was largely because Vegard and I tried to take over everything and be both business people, sales people, support people, marketing people, developers, administrators, janitors, secretaries, and whatever else we needed done.

I don’t even have the code still. Benny Samuelsen at ISPHuset, who purchased the remains of the last company may have a copy somewhere, but I don’t.

When I saw SharePoint 2007, however, I saw some of the same features or at least the same ideas implemented by a huge company. The ideas were there if the execution wasn’t quite the same. Perhaps then, Microsoft could pick up where our dreams and products had failed, and I could just ride the 9:30 innovation express from Redmond to bliss.

So, I started doing SharePoint because it was innovative. It had the right ideas.  It was awesome.

SharePoint still is awesome, but the big, big problem is that it is exactly as awesome as it was in 2007. Not more awesome, not less; just as much. That’s because there hasn’t really been any innovation on the platform. The things that sparked my interest in 2007 haven’t changed. They haven’t been driven forward.

Note that I’m saying “the platform” here. I don’t care about SharePoint the product. That’s boring, predictable, and stale, and that includes Office365.

That’s a bit sad because there’s so much stuff that can be done with SharePoint still to make it even more awesome. That had nothing to do with putting more bells, whistles, and colors on it. It has to fundamentally change the way organizations think about data.

SharePoint 2007 blew everyone’s mind. Behind the scenes, everyone who could tie their own shoelaces saw the potential. I still get erotically aroused when I think about content types. The disconnect between SharePoint the engine and the UI is brilliant. That’s when Microsoft laid the foundation of SharePoint’s success.

Yeah, there’s a disconnect between SharePoint the engine and the UI. In 2007. You know, what’s now being hailed as “the most awesome thing since sliced bread” and “newer than an infant with birth goo on it”. It has been there since 2007. You just haven’t seen it, likely because you’ve been too busy crucifying those that do see it.

Then, in SharePoint 2010, Microsoft fixed some of the issues and created a more polished product. It wasn’t very innovative but it was more stable, except in the parts that were completely new and most of the SharePoint Server crap. SharePoint 2010 was really a version 2 of SharePoint 2007. It wasn’t a new product; it was just a much improved version of the same product.

But in SharePoint 2013, there’s nothing. It’s not better in any way. It’s far worse. It’s less stable, it runs slower, requires far more hardware even with that lower performance, and there’s nothing, absolutely nothing new. There are a few new apps on top of SharePoint, but in SharePoint itself, innovation has just stopped.

You see, the bones that get thrown to the community isn’t innovation; it’s marketing. The world has thought of all of this before. I know, because I did it myself, and I just plainly assume that means a lot of other people have done so too.

Imagine, when two kids in a small rural town in backwards Norway could create NB2 Publish, doing pretty much everything SharePoint does and more in two years, what Microsoft could create if they were truly innovative. There wouldn’t be a competitor to SharePoint ever. Microsoft would be decades ahead.

Instead, they suck the motivation out of the community and hope that you all bite and get distracted like the puppies Redmond wants you to be. Then, they use your distraction to suck as much money out of their customers as possible. And they lose the race to have great platforms.

Microsoft has one more chance to be great again with SharePoint 2016. If they fail, and you can start realizing they are when you see buzzwords like Social Enterprise Cloud and other terms from the BS Bingo, then some kid in a rural town somewhere in Scandinavia will launch the next thing that just obliterates SharePoint.

And you know… You’ll still be a SharePoint professional at that time and go down with it.

Thanks for reading,


Pin It