The Success and Failure of Ninja

Sad to hear the overall experience has been so negative for him. Ninja has certainly had a large impact! I can relate to the open-source burnout, even though I've experienced only a tiny tiny fraction of it compared to the success of Ninja.

Re. speed, I wonder how much of Ninja's speed over make is thanks to Ninja's "deps log" binary format. In my (fabricated) benchmarks, Make spent 98% of its time processing the compiler-generated ".d" files that are used to track dependencies on header files: https://david.rothlis.net/ninja-benchmark/

I'm still using the crash-only principle as much as possible; the daemon simply exits if build files or arguments change, rather than attempting to update its state. Although cross-platform IPC is complex, once that's abstracted away the changes to ninja itself are small and non-invasive. I think it's less complex than other proposals to speed up ninja startup, like a new binary input format.

Anyway, if anyone is working on a very large project and wishes ninja started faster, try this PR: https://github.com/ninja-build/ninja/pull/1438

Then try to have a better attitude when leaving issues on github or whatever. Be thankful. Take responsibility if you want a change to make the change yourself. Offer it as a PR but don't expect it to be pulled. Others can grab the PR if they want it even if the maintainer doesn't feel it's a fit. If you have a suggestion offer it as a question like (would it be faster if this did X instead of Y? or would it be useful if feature A existed?)

I'm not good at this myself but I'm slowly getting better over the years.

Also also, I wish there was a better way to express thanks. In the article it was mentioned that thank yous are rare where as angry demands are common. But, there is no easy way to express thanks. Like opening an issue and saying "Thank you" is frowned on. Even leaving a comment under a tech blog post that just says "thanks" is considered by some to be unwanted noise. I don't have a solution here. Maybe you have some suggestions?

Also, if you feel it's appropriate, sponsor your favorite projects. I've wondered if there is a good way to promote sponsorship. I don't want to brag that I'm donating each month to various projects but I do want more people to consider sponsoring. Especially user oriented projects like say Blender, software that 100k to 1000k people are using which would normally probably cost $1500k-$3000k a year, maybe a coffee a month would be worth if you're using it often? Same for things like Kodi? Or VLC? both of which I've got 1000s of hours of usage out of.

I've been developping a small cmake frontend which uses it by default as well as generally optimizes for build speed - https://github.com/jcelerier/cninja

Being short and not very specific, it probably takes close reading to get much useful from it, but not a word is wasted, and nothing in it will lead one astray.

This is something to emphasize.

I often feel that my productivity is strongly linked to the latency of actions I do. I like to play around a lot if the latency is low. Once it becomes higher, I generally don't do that, and in principle I often additionally think about how to work around stuff, maybe write another complexity layer on top, maybe even do less testing, etc (many of these things just unconsciously). So it does not only adds the latency time, but really makes the whole development cycle slower, and less optimal. Also I tend to get distracted more easily. When I know that the next action (compiling, startup time, whatever) takes 30-60 seconds, I will definitely not just wait, but do something in the meanwhile. But also you cannot really do something productive in that time. So I end up checking mails or HN or so.

Also, since I started with my PhD, doing research on machine learning, I discovered a whole new scale of this problem, which I had not experienced before. Now the latency time has usually increased from a couple of seconds to a day, or a week. This drastically changes of how you work. To stay productive, you have to parallelize your work. When you are trying out things, you will try out many variations in parallel. Also you will look at the intermediate results, and maybe already draw conclusions from that.

If there is a chance to refactor your current pipeline to reduce that iteration loop time, or the wait-time (which might be the startup time of some tool, or whatever), I think it's very worth to do it.

And they shouldn't have been surprised at the number of Ninja users that were on Windows, Ninja is so much faster than the alternatives if you are using CMake on windows.

> I mentioned that I stumbled through Ninja's design. I regret not spending more time researching before building, ... Since then I have come to appreciate how important it is to actually understand the design space when building a thing. I now find myself noticing how rare it is for programmers to discuss related work and it now drives me mad.

FWIW, I think this is a key take-away.

open source maintainers this is a public service announcement. You're killing yourselves by being too nice. Don't be afraid to embrace your inner despot because really that's what you are when you are maintainer over a project. you need to be sort of a rougher, less experienced than, less polished version of Linus's or Guido's benevolent dictator for life. if you don't like something just shut it down if you don't like an issue just close it if you don't like a PR just close it if you don't like a request just deny it.

if this is starting to rub off on you in a good way and you're liking what I'm saying well then just double down and do it. embrace your inner despot. it's okay. if you're still sitting on the fence let me bring you to the good side with a little bit of advice, if you need to have it sold you like this. That's fine. it's not about you. keeping you in the best mental health possible, taking care of you is really about taking care of the project and all the people involved in it. you need to come first so that the project survives and can thrive. so uncomfortable as it may be to embrace your inner despot that's the best way to secure your own mental health.

clear boundaries. unhesitating expression of what you want to do. no apologies.

they want to fork it? not your problem. stick a fork in it.

you don't like the way someone's behaving? block them.

you can choose to make this a great experience for you I believe. you just need the discipline to stick to that path. at every branch in the road choose this: what you want to do and only what you want to do. no compromises. That's the discipline you need to practice. if a project that used to be fun and give you a whole set of positive emotions, opens up, that should really only increase the positivity for you once you share it with others. I believe if you picked the right path by embracing your inner despot you can do that. you end up with a lot of people expressing their negative emotions, but you know what? who cares. their feelings are not your responsibility. it's not your problem.

be a despot. you'll like it. and it might be the only chance you have to do that. and I might be the way to save your mental health and your project.

and maybe just maybe if you be a despot the community will change. people who support you will gather around you and protect you once they see that strength which is inspiring. this drink that you stick to your principles and your vision. and maybe just maybe if you're lucky there's no guarantee but maybe the community will start protecting you. and if they do well just don't get soft. keep being a despot because that's what you need to do that's your job. you created this thing it's your responsibility to keep it on the best possible that involves keeping yourself on the best path possible. you already know how to do that you just have to choose that at every little decision you have. if you're not ready to make a decision right now just aren't. delay it until you feel ready to do it.

good luck. end of message.