Freecad isn't open source software!

If it is impossible to get something compiled, it can't be open source.
When you can't compile it, all, that is left, is to use a binary.
If there is only a binary, it isn't open source.

Seriously: If you are participating in an open source project, please make sure, that compiling from source is a viable option for the generic gentoo user. Thank you.

Contra argument: A maintainer isn't responsible if something does not compile on rarely used operating systems.

It builds in CI and more often used Linux distributions got it to compile (or where did you think you got your binary from?) as well.

@sbiewald
Yes, the .appimage has obviously been compiled somewhere.
But so has been MacOS...

And i get, that the sets of people managing to somehow compile it and the set of people being developers of the software aren't strictly identical.
I just am really pissed about, that after getting all that absurd dependencies together (the count of new packages just for FreeCAD was 106 and a few where so obscure, i had to dig them up in two other repos), it didn't even compile.

I actually think, it is a systemic problem. Bigger opensource projects tend to generally be absurdly hard to get to actually build outside the maintainers' machines.
If Chromium, Firefox or LibreOffice wouldn't be available with a well-maintained ebuild in the repo, there probably would be a zero chance, that i could ever hope to get them build before dieing of old age while trying.

But on the bright side: Code maintainability is of no issue if whoever comes after you can't get it to build anyways...

@Oktokolo It does not compile outside the maintainer's machine? Come on, that's why they are using CI, it is a reproducible environment for exact that reason.

Don't get me wrong, it is annoying as hell to not be able to compile some software - but I hardly see the maintainer in fault if it does not work on exotic systems I chose by myself.

OSS projects should have clear documentation including dependencies, plus clear and working build instructions. Otherwise, this is an outright bug.

@sbiewald
I actually think, that the CI makes things even worse. They probably got that working in a docker container once and then never thought about the complexity of the build process ever again.

But if anyone wants to build it from source somewhere else, they have two options:
Use their VM image or docker container containing the build environment - wich basically equals getting a blob...
Or trying to do something, wich the devs themselves maybe did only once a shitton of versions ago: Actually getting it to compile in the wild.

I am aware, that my rant is unfairly singling out a tiny team doing excellent work building a free and open parametric CAD/CAM software from scratch.
My emotional attachment to it (i even spent weeks learning how to do basic things with it despite having a pirate copy of SolidWorks lying around wich i obtained for a friend) definitely made me overreact.

But i really don't care about web browsers or office suites enough to rant about them...

With bigger projects, OSS often goes downhills. The build chain is insane so I won't actually figure out the root cause, hence no patch suggestion, and bug reports are generally ignored.

I've actually stopped filing bug reports for sizeable OSS projects unless it causes some weird workaround on my end. Then I file one, but only as reference for my own documentation. I don't expect anything to get fixed because it won't.

The quality of OSS tends to decline with increasing project size. Due to the insanity that is the build chain, I will not attempt to determine the cause; as a result, you will receive neither a patch recommendation nor a response to your bug report.

I agree that build dependencies in OSS should be documented for the convenience of prospective contributors, however I don't agree that the build process must be simplified just for the user's convenience. It's not something users normally do. If Gentoo users want to build any odd project not specifically designed for Gentoo, they're welcome to spin up an instance of the CI container. I hear Gentoo users also don't like Rust because it's another toolchain "they have to be aware of". They don't. By the nature of open source no one stops them from building from source, but an easier path exists, so the developer isn't forcing anyone. Compiling everything from source is an arbitrary self-imposed restriction that should be the shared burden of people who share the restriction and no one else.

Arch also likes to build third party software from source by the way, so I have no problem with the idea. I just think the developer's responsibility ends at making it possible. Anything else; customization, compiler independence, toolchain reuse, are all extra.

@lorentz It's just as bad for the distro maintainers because Rust bypasses the dependency management with its own Cargo crap - an idea so bad that it's no wonder Rust came from a web company.

Usually, if you have a bug or security issue, you fix the library, and all applications profit immediately. Not so with Rust where you fix the library and then have to keep track of every single application that uses it and also have to update that, plus that you have to rely on Cargo as another point of failure.

This is gaining developer convenience at the expense of everyone else down the chain. It's just not sustainable and doesn't scale.