This is a bit ridiculous on the other direction. It's like your main job is putting nails, and at the end of the year you have only put 29 nails. Sure, nails per day is not the best metric, but if in one year building furniture you only put 29 nails in total it's definitely not a good outlook for your productivity.

But his job wasn't putting nails. In this metaphor, his job would have been increasing the furniture company's output and profits; maybe he found another of doing it. Perhaps for instance, he figured out that instead of nails, he could utilize another joinery approach, like dovetails.

Sure, that's a fair point. I don't know enough about the exact job, internals, etc, just commenting that while commits/day or /week or even /month might not be the best metric, if you are (which I'm unsure here) hired to do that then if you only do 29/year, yeah you are probably not doing your job.

Last time I ever squash commits, reading this discussion.

When that “carpenter” is also answering the phone and doing quotes for work, apparently. If Henry is also the community manager and main fundraiser (which from the sounds of other posts he is), I’d argue that the last thing you’d want him spending time on would be code.

If he was a smaller fraction of the work force, that would make sense. But if you have a single full-time worker who is receiving about 2/3 of the payroll budget, I'd argue that you can't afford for them to spend most of their hours on business stuff.

Business stuff is what pays the bills. You can't have 2/3 of the work force just merging PRs and find out 6 months later that nobody paid the taxes and you won't be bringing in enough money to make payroll next month.

I wasn't saying not to do administrative tasks, but that they shouldn't be over half your entire company's work-hour allocation. Even with fundraising in there too.

Imagine if you had 3 employees and 2 of them were HR. That is not a good allocation of labor.

If you're including sales in the bucket of administrative tasks (and fundraising is very much equivalent to sales), many successful companies are at or near 100% administrative tasks.

It does seem odd that so much of the work would go towards paying to keep looking for more money (fundraising for fundraising), but there are plenty of sales oriented organisations out there who don't make anything. It's just odd in this case that an OSS project seems to have gone on that direction.

I suspect nobody should be earning such a salary working on a project like that.

It's like having a startup with 1 full-time salesperson and 3 part-time engineers. It would never work unless you already have a product (which Babel does).

I sort of get the idea of spending your money trying to sale an existing product but it doesn't seem to have worked in this case. That doesn't mean allocating the money differently would have worked either (arguably it would have been better for current patrons though).

This is what happens when you spend your eng career working at a company that doesn't have to sell products.

Not per day, but over an entire year. If you're making things that are held together with nails then that is not a bad starting point for evaluation.

Not everything is held together with nails.

Yes, that's why I put in the "if".

We can change the analogy to also look at how many pieces of furniture produced, or whatever, but it starts to just be a pointless tangent.