I cannot write software outside of Google anymore

Not trying to start a flame war here but… who cares?

I’ve published open source while working at faang myself and they all have internal build tools, version sets, etc.

Plenty of employees still do tons of open-source.

Everything from the build system to the coding style oozes "NIH", even seemingly simple things are overengineered to fit the "Google way", and god forbid they use any standard tools or even ideas from outside Google.

It wouldn't be a problem if the Google tools would be great, but they feel clunky and as if they've been frozen in time 10..15 years ago.

It’s like one of the biggest problems that seems to be a plague related to build systems is that there is a point somewhere around the level of a makefile that a very large number of programmers can understand but is hard to maintain so various companies build infrastructure on top of the makefile that is semi custom.. then another engineer comes along and builds abstraction on top of that. So you end up with this house of cards that depends upon python 3.8, etc etc then finally there is a makefile.

I do wish all of these whacky build systems would be required to have some choke point where it prints to stdout “generated makefile at path = /……, continuing in 3 seconds… running make -f xxxxxx”

You choose whatever build system you like, create a single-line "install.sh" which runs some "apt install" command, and you are done -- things just work.

The main downsides are that packages are somewhat old, and that your users need the have the same distribution. But containers help a lot with the latter problem.

When AT&T dissolved the group that had been maintaining a bunch of unix software, and other people had to try to pick up maintenance of ksh, they discovered a little thing called AST.

> You can use any 3rd party open source library you like, as long as you use their build, package management scheme, compiler, what have you. But you cannot then use any other open source library.

Most everything I've seen will happily accept whatever I've installed into /usr/local/lib and /usr/local/include. Yes, you have to build the thing first. But it's gotten so much easier & better, generally. Sure there's configure, cmake, make, different toolchains... but most of the build tools are pretty flexible & configurable in pretty standard ways. Way more projects are toolchain neutral. (That said, webassembly/emsdk adds a whole new depth of complexity to everything.)

And meson is kicking ass & taking names everywhere, is so much less of a "write it yourself" bag-of-tools and so much more "it just works" framework.

[1] https://www.aosabook.org/en/posa/ninja.html

The bigger takeaway here is that working at a large company, for any length of time, tends to sink you in (rather than lock you in) to their ways of working and it can be rather difficult to step into the wide open source world afterwards. It is not out of laziness, but out of learned ways of working and domain knowledge.

It is difficult to extricate yourself from "The <Company> way"...sometimes with panic and dismay at the sheer amount of options out there, that simply aren't as interoperable as "The <Company> way" was. This is a legitimate and valid pain point that professional software engineers, working in companies, face in their careers.

A smaller but equally important thing to note is mention of the number of people working on the build systems internally, that make and maintain interoperability between both internal and 3rd party libraries and tools, to create a smooth build system.

Someone has almost certainly packaged the thing you want with Python bindings.

I know some people manage to do it, in the same way that some people manage to write complex software that uses many libraries in C++. Are they just smarter than me? Or have they simply {discovered, bought, created} a superior toolchain?