By popular demand I have decided to continue my series on selling open source (Part 1, Part 2).

A couple readers both reacted my previous blog with more or less the same words: This is great, but what about the level of mission criticality of the use case? Surely you should count that as a third variable since it impacts the likelihood of a user becoming a paying customer?

Lead qualification

So, yesterday I wrote about what the sales funnel looks like when selling open source software, compared to what it used to look like when we sold closed source software. In this post I will build on that theory with some practical conclusions. (I assume you've read the first post.)

Why modeling your business matters

When running a business we need to do budgeting and other planning related activities. If you don't, you'll probably run out of money at some point. Also the point of planning is to capture as much of the business potential out there as possible. For example, to sell 5MEUR next year, do we need 5 sales managers or 6? (...and, can we afford 6?)

Since I joined MongoDB it seems I have mostly been doing technical blogs. Yesterday I had a conversation with a long time friend from the open source database scene, which inspired me to jot down some observations on my long time favorite topic: open source business strategy.

In fact, this will be very much a Selling Open Source 101 blog. I've come to realize that while what I'm about to write is well known to open source oldtimers, those of us who were lucky to work at Red Hat and MySQL and other first generation open source companies, these ideas are not necessarily well known to many executives and sales managers working in open source today.

I'm preparing to do some simple MongoDB hackathons in Scandinavia, and because I don't want to forget how to do all the steps, I actually wrote down an example exercise.

This is a simple and fun exercise just to get some data into MongoDB and then get it out again. We're going to use some awesome JavaScript tools for the out part: Node.js and Crest for a simple HTTP API, and Angular.js to draw the pretty pictures. So this is not just a MongoDB hackathon but more like a fullstack JavaScript or MEAN hackathon. (Strictly speaking there's no Express.js, so maybe this is a NMCA hackathon?)

Install MongoDB

The usual apt, yum and brew methods will work for this tutorial.

On May 5th I will be speaking at the ICT Expo in Helsinki. On home field, so to speak! This is the major Finnish ICT event and MongoDB will be exhibiting together with our Nordics partner Altotech.

The title for my talk is "5 Reasons that made MongoDB the Leading NoSQL Database". In preparing the talk I came to think of several MongoDB features that are great, but in consideration are clearly NOT reasons that make MongoDB stand out against other NoSQL databases.

Why? Because these are typical traits of any NoSQL database. Here's my Top 5 list of non-reasons:

As someone who worked for 2 decades with Internet technologies, and as an active blogger and microblogger myself, one of the most inspiring and powerful experiences have been to observe how blogs and tweets have the power of transforming dictatorships into democracies.

In that spirit, I'm publishing below a translation of a blog post (original title: В ПОИСКАХ ПРИКЛЮЧЕНИЙ - Фашисты на Майдане) by the user tummanaya_feya (which may or may not be her real name, as I don't know her) of LiveJournal. It appears she is a young Russian living in Kiev, writing to her mother in law, who lives in Moscow.

Last week I posted a challenge about ordering fabric for a bunch of different flags, which can be conveniently solved with the MongoDB aggregation framework. Did you figure out the answer?

So we have a bunch of these flag orders for different countries:

{
	"_id" : ObjectId("52a71923cd4dd732cd060204"),
	"country" : "Norway",
	"colors" : [
		{
			"color" : "red",
			"fabric_units" : 3
		},
		{
			"color" : "blue",
			"fabric_units" : 2
		},
		{
			"color" : "white",
			"fabric_units" : 1
		}
	],
	"num_flags" : 2
}

And to calculate how much fabric we need of each color:

> db.flags.aggregate( [ 
    { $unwind : "$colors" }, 

One of the really cool, well designed features in MongoDB is the aggregation framework. Basically it is the feature that brings MongoDB query language on par with SQL in feature richness. Most importantly, it fully supports sharding for scale-out and parallel processing. I've had a lot of fun with it.

Last night I accidentally came up with a fun exercise that you can solve with a nice aggregation framework pipeline. I'll present it as a challenge, feel free to suggest answers in comments. I'll share my answer next week.

Suppose you work in a flag factory, and you have received the following orders:

> db.flags.find().pretty()
{
	"_id" : ObjectId("52a7189ecd4dd732cd060201"),
	"country" : "Finland",