As mentioned previously, Monty Widenius is starting his new company based on some interesting premises. With Zak Greant they have co-authored a pamflet where they outline a blueprint for Open Source companies. In many ways this could be considered the "Dogme 95" of Open Source businesses:-)

While Zak has been employing these principles in his company already, Monty is now beating him to actually having more employees than himself, thus it will be interesting to hear how these principles play out in real life.

The first point that strikes me is:

Transparent: We communicate in an honest and genuine way. Any information or process that can be made open, will be made open.

When I wrote my book Open Life, I ended up dreaming up a company that would be radically transparent. I'm not quite sure if this is intendend to include things like the accounting of the company, etc, but I hope it will. This is the most interesting aspect of this, which I look forward to seeing develop out in practice.

Under "Methods" they also list:

Consensus-based decision making

I wonder what exactly they mean by this. In many Open Source projects there is a form of "Consensus based decision making" where everyone brutally disagrees about everything, then the leader of the project tries to make some wise decisions within that chaos. If this is what is intended, then fine.

OTOH, if this refers to some formal method of Consensus-based decision making, which I know for instance some environmentalist groups are fond of, then I beg to disagree. That would be a terrible way to run a business and I'd hate to work for such a company. Usually it just means that the one who is the last to give up in an argument wins. (I see the point how that might be interesting for Monty :-)

Same goes for being a democratic company. Like Timour says in the comments, you cannot make great technical innovations by a democratic process. I similarly believe you cannot make an efficient business run with a democratic process either.

From here we actually come to the main part I want to criticise: the section "Decision making processes" introduces some complex system of an Advisory board and a Governance board that have power even over the CEO. By now Monty's "disagreements" or rather animosity with the MySQL CEO are well known, and knowing that I can immediately comment on this section:

Monty: this section seems to me like you are patching what MySQL was, and it is messy. It is complex and likely very inefficient, and you could probably achieve what you wanted with a much simpler approach.

The point is this: You want the employees to have a say in things: Make employees the owners of the company. The owners are the ones who should have the power to make ultimate decisions, including firing the CEO. I have worked in the public sector and I have worked in the academia and I learned to appreciate the "direct command lines" you have in the business world. Ultimately you have one person in charge for any given thing, he is responsible for making those things happen a) at all and b) in the right way. And if he doesn't then you replace him (which doesn't always imply firing anyone). Your system of having "MySQL Ab plus a lot of complex advisory boards" simply will not work. Start from scratch, don't patch something you don't like.

There are then some questions like what if you want to take on investors. You can still do that, just make sure the employee-owners have the majority voting right. You can split up ownership in A and B shares so that for instance privileged A shares have 10 votes and the normal B share only has 1 per share. I believe Google still has this system, and it is common in the media. It used to be common in Finnish companies too, ranging from banks to forest industry. (Presumably to protect national interests while taking in foreign capital.)

Of course your company might also be fundamentally averse to investors. It seems to me some of the former MySQL employees who created their own companies have chosen to live funded on revenue growth alone. Perhaps they are happier that way?

Then finally a slightly different topic I disagree with:

The company or its individual business units should not grow until they are
unmanagable by the chosen methods. If this happens, then the company needs to
be split up or re-organized into largely independent business units.

(From talking with Monty recently I hear 20-30 persons is the limit when a split should occur.)

This is an interesting concept which on its face there is nothing wrong with. But as it happens when I first discussed these ideas with Zak right after you had written this, I was myself employed in a company whose strategy it was to spin off an endless sequence of 20 person companies. It was terrible! It meant you could never take on any large projects, because you were doomed to always remaining small. In theory the small spinoff companies were supposed to cooperate, in practice there was no incentive to cooperate. I at one point chose to cooperate with my competitors rather than going through the bureacracy of cooperating with my sister companies. For me this was a very demotivating structure overall also because I was myself intimately involved in starting at least 3 new projects, all of which where then spun off as separate companies thus completely excluding me from any monetary or emotional reward. (And at least 2 of which failed miserably in incapable hands).

In an Open Source setting I admit this idea is interesting, because conceivably if you had hundreds of 20 person companies collaborating on one Open Source project, it could be very successful, and this is different from the closed and proprietary setting I was working in. But there is some game theory to it too: what if one of the companies decide to break the rule and grow bigger than the others and then come to dominate the ecosystem?

So I'm open to you surprising me on this point, but a priori I deserve the right to be critical.

This leads naturally to one closing comment:

- Each employee will be assigned a VIP number of 1-5 (5 highest) to
describe his importance for the company. This number is used to
calculate the end of year bonuses and 'sell-shares'. The VIP number
will be adjusted each year as part of a employee review.

? Who sets the VIP number?
? How does the VIP number change over time?
? How do we stop people from feeling bad about their VIP number?

If you decide to stick to being a 20-30 person company, you don't need a formal system for such a VIP number. IMHO more formal HR processes are needed when a company grows towards 100 or so.

**

That's all, good luck with the experiment!