Great observation! I didn't think about the FOSS model of management as I was writing this - only startups. The meritocracy model works even better with FOSS - blowhards who can't deliver don't get very far when there is nothing but delivery to be done.

Both models (FOSS/Startups) are somewhat vulnerable to those who are the loudest winning by sheer volume. In both cases the BDFL/CEO can intervene but it wastes time/energy when it's needed most.

True, OSS is also usually more philanthropic in that many times it isn't directly a paid situation or most times which changes the dynamic. However many people do OSS to attract business with as well or specifically to do business on that isn't controlled by a company i.e. Linux, Rails, Python etc.

I am sure in a flat company, compensation is probably the toughest part as it can easily turn into a popularity/tribal thing possibly unless there is some set ranges and agreed upon structure. I wonder in a flat company if compensation needs to be more open.

I haven't heard of enough companies that are open about their open compensation, but Buffer seems to have it handled pretty well: https://open.bufferapp.com/introducing-open-salaries-at-buff...

The difficulty lies in quantifying experience - there loads of ways to pull that off (and none of them quite wrong). Years of experience, type of hackery, FOSS contributions, etc. I'd say the best option would be to pick one and stick with it. If you're properly open about it, those who take issue with your system won't apply.

Open-Book Management:

http://en.wikipedia.org/wiki/Open-book_management

Open Source is in fact a democracy. The most general definition of democracy is: Everybody in the group has the same amount of power, which is defined by "shared understanding" how things should be, and usually by having an explicit rule in place that enforces the same amount of power for everyone (in small groups, the rule may be just informal).

In OSS, everybody has the same access to the source code. That's the power from the definition, and the OSS license is the explicit rule.

Because of the explicit rule, if someone goes power hungry on one extreme, the rule guarantees that he will be ousted (via forking the source), and other extreme, if someone is not interested in politics (like someone actually working on the code), they won't get screwed, because they will always have the source code access according to the rule.

People in the past tried it, naively, without the explicit power rule. That was the MIT license. But they got screwed (divided and conquered) by people who wanted power, who wanted to close the source. That's why copyleft (i.e. democracy) was invented. (This actually happened on the metagame level - now the BSD type licenses mostly work because people always can fall back to GPL.)

This is not universally true. In fact, most larger successful projects have a "Benevolent Dictator For Life", either explicitly or implicitly.

Linus has Linus. Python, Guido. Ruby, Matz. And so on.

True but those guys are mostly language creators which are unique and rare and kind of needed to get people to start using them. Many of these guys worked on the languages alone for years if not near decades before others come in. The BDFL gives some hope that the language will stay true.

Other projects a BDFL can emerge or the original creator is polled for direction but largely they are there to keep trust in the platform.

Here's some really cool code_swarm looks at Guido and his long journey as the sole fighter for Python, bring it to the masses alone for 5+ years: https://vimeo.com/1093745 This video gives a unique look at the meritocracy team behind Python and how they contributed over time, fading in and out.

See all of them here: http://vis.cs.ucdavis.edu/~ogawa/codeswarm/ has Eclipse, Python, Apache, PostgreSQL.

Yes, if one person has the authority to accept changesets, and other people do not, that's inherently not a flat structure.

> "Open Source is a flat structure and seems to work in many awesome ways." and "... naturally occurring ones seem to evolve better and work better."

I agree that open source is awesome but successful projects are not at all 'flat' structures. Just think about all the governance processes that are necessary once a project grows beyond a certain size. These allow a project to achieve some kind of longevity. Simply thinking about who has commit access should indicate that there is clearly some form of hierarchy (at least, some form of 'in-crowd').

If you think that the 'naturally' occurring hierarchies work better, then I'd posit that you've only been in the 'in-crowd' for those projects -- of course it's difficult to see the downside from that vantage point.

You make a good point but I think in OSS projects merit is the only product being sold so meritocracy works. In a for profit organisation, you would always need a management layer because the focus should always be the product and not the individual contributors.

Even then, meritocracy is a pretty loaded term. The rewards don't align with the accomplishments. Being active in open source either requires huge sacrifices in time and career advancement or it requires an employer who provides time and opportunity to work on open source. That's not quite a meritocracy, as some are set up to succeed better than others regardless of skill.