Open Source Doesn't Require Providing Builds
codeengineered.com
codeengineered.com
I'm using a router distribution -- no names please -- where the firmware build process is so intricate that their documented way to build LTS .iso images is via a docker based system. I've had very little luck (until recently) in getting that to actually work.
They provide nightly .iso images, but charge an arm-and-a-leg for the LTS images.
I've tried to use their nightlies, but they were subject to considerable churn in the last few months. That resulted in broken firewalls/routers.
I will NOT trust my firewalls to that, sorry.
In their defense, they _do_ have a way for "community members" (i.e. folks unwilling to pay $1000s/year for a stable build) to gain access to the LTS images. However the bar they have set to gain access is so high that my filing a bug they graded as "high priority" and then tracking down and verifying the workaround for a release candidate didn't qualify me to access the images.
I agree there is a gray area, and that the core developers deserve to be paid. I am actually willing to pay them for their software, but not $1000s/year.
In my honest opinion, they have crossed a line.
(Edited: changed "fix" to "workaround" above.)
What you are referring to is often labelled shared source. For instance, Microsoft offers the Windows source code to some customers for reference purposes, but that source is not allowed to be built or distributed.
It's fine to build a business model around your open source project. It's fine to charge for builds as your business model.
What is not fine is purposefully obfuscating the process needed to build that open source software to encourage users to just pay for the builds. That's shady and counter to the spirit of open source.
I've not used VyOS in recent years, but their pricing structure does seem designed to convert users to customers.
$ git clone -b sagitta --single-branch https://github.com/vyos/vyos-build
$ cd vyos-build
$ docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:sagitta bash
[docker] $ sudo make clean
[docker] $ sudo ./build-vyos-image iso --architecture amd64 --build-by "j.randomhacker@vyos.io"
[docker] $ sudo mount -i -o remount,exec,dev /vyos
[docker] $ sudo ./build-vyos-image iso --architecture amd64 --build-by "j.randomhacker@vyos.io"
[docker] $ exit
$ ls -l build/*.iso
-rw-r--r-- 1 root root 502267904 jan 22 23:55 build/live-image-amd64.hybrid.iso
-rw-r--r-- 1 root root 502267904 jan 23 00:04 build/vyos-1.4-rolling-202401222255-amd64.iso
Is this harder than downloading an .ISO from a website? Yes, of course. Do I expect everyone to be able to follow the manual? Probably not. But that's why there are ways to pay VyOS, this is a company doing open source after all.
If you can spare some server capacity and are willing to put in effort, you could set up a script to run the build process automatically and host the ISO files for everyone to download, as long as you remove all the trademarked branding of course.
Similar model to Xen Orchestra, as I understand it. (Which is another product I've never used myself, coincidentally.)
If your build process is so bespoke/complex (or can only be produced with licensed, hard to obtain software) and there is no way for a layman (meaning someone not well versed) in the specific technologies involved to produce a binary, then maybe it does require providing compiled software.
On the other hand, if anyone with say, a suitable host could download the software, and produce working binaries with a minimal time and knowledge investment, then maybe not.
You're not entitled to builds. You're not entitled to an easy build process. You're not entitled to access to a special LTS branch.
While I agree that it's annoying when an open source project is difficult to build, that's an opportunity for an interested contributor to step in and try to make it better. Not an opportunity for you to whine about it.
There is no "gray area". Consider if this was a proprietary product: you'd get literally nothing without paying, and even if you paid, you'd probably just get a firmware binary, with no access to the source.
You sound like an entitled person who thinks other people should make your life easier and give you stuff, without compensation. I suggest you adjust your expectations and stop assuming people should and will do free labor for you.
As an aside, I'm not surprised the build process is complicated: this isn't building a single library or binary, it's building an entire OS distribution. I'm sure the entirety of Debian or OpenWRT is difficult to build as well.
Edit: This bit just really got to me:
> I will NOT trust my firewalls to that, sorry.
Then pay! This idea that your firewalls deserve to be safe and secure and maintainable just because you want them to be, but are apparently not willing to pay for the software to make it so... do you seriously not see how ridiculous that is?
If you're unhappy with how this particular vendor gives away its free stuff, and don't want to pay for the product that you really want, find another vendor. If none exist that you're happy with, that is not the problem of any of these project maintainers. It's yours, and you get to solve it by writing code on your own, or by paying someone else to do it for you. You're not entitled to anything!
Regardless, the whole "free as in speech" (vs. "free as in beer") thing isn't saying that the code is like speech. It was just a way for the FSF to distinguish between the two confusing (in this context, at least) English meanings of the word "free".
Not saying everyone has the skills or time or even desire to contribute regularly to an open source project. And that's fine! But that doesn't mean whining about (what you see as) a project's deficiencies is ever cool.
(Note that I'm fine with people writing up constructive criticism. But just stuff like "this project doesn't provide release builds unless I pay and that's not fair" is just entitled nonsense.)
Hoo boy, do I miss the days of the usenet killfile.
If their paying customers want something, then that's perhaps a different story, and is governed by whatever agreement (tacit or otherwise) is in place for the purchase.
But if you aren't paying, you aren't owed anything. Not a single thing.
I wished those people could be transferred back to the pre-FOSS days when your disassembler was one of the more critical tools in the toolbox if you wished to fix vendor bugs. I distinctly recall reverse engineering the ROM of a laser printer board to repair a bug that the manufacturer just couldn't be bothered to deal with (Tall-Tree systems Jlaser, I'll never forget). That would have been a lot easier if it had come with source code. These days for me it's either open source or you can keep it.
I wonder if this shift can be attributed to influencer / social media culture. That is, these things exist to get "likes" and "engagement" and build "communities" and "brands" and whatnot. So your average person, someone who even knows a bit about open source, might think that any maintainer worth anything would want those things as well, and see it as not just worth it, but required to provide all the extra free labor required to get those likes and promote their brand.
These scripts may or may not have worked for you. The BSD user ports collection was at least curated so that these scripts all worked.
A bunch of scripts in a repo which done something usefull for someone when called in the right order can be very much open source.
Just because a commit accidentally broke the cmake file in a project it doesn’t suddenly become “non open source”. Prevents you from building it for sure, but doesn’t make it non open source.
Yes, we know it is mot requirement. But it is nice and convention to do.
Building Go programs is only easy if you're building Go programs in your everyday life. The same can be said for any language (just cmake/make/cargo/npm/gradle build/install/package!), there's really no "easy" way to build any software unless it's well-documented in a way that will guide you through the build steps on every OS under the sun.
Of course no developers have any kind of obligation to provide build steps or binary releases, but don't think it's easy because you find it easy. I remember trying to build a Go program the first time and needing to figure out how to install Go in a way that didn't mess up my package manager because Google expects you to untar files manually rather than provide some kind of software repository for automatic updates.
The funny part is that those who are the target of certain articles are those who will never take the time or chance to give up their entitlement, I rather not interact with that part of the population at all, thats the code, thats the license, do what you can and don’t bother me, but a lot of open source maintainers are way too nice
I'm sure there's more I'm missing; these are the first I came up with. Do people expect good documentation these days? A Discord server or other chat forum?
I will admit, I do have some expectations of the free software I use. I expect it won’t “rm -rf” my files, or mine Bitcoin.
But builds? Open governance? Maintenance? Good grief, what basis would I have to expect any of that from something for which I paid absolutely nothing?
From my perspective users are owed nothing. Everything on top of that is a bonus. If the maintainer doesn't have a bug tracker or a way to provide feedback, or doesn't even want to have a public VCS, but just posts tarballs to a website every time there's a release, that's their prerogative. People are certainly free not to use it if they don't like the development process, but the developer doesn't owe anyone anything.
I do wonder what's responsible for this shift. A shitty part of me wants to blame Millennial/Zoomer shifts in attitude based on how they were raised to expect to be handled the world on a platter, but that feels like lazy, prejudicial thinking. But I'm at a loss for what the real cause might be.
Edit: Thinking about this a bit more while writing a different comment, I wonder if it's a result of influencer / social media culture. People in those spheres want likes/engagement, want to promote their brand and get recognition, etc. So your average person might think that any open source maintainer would want that too, and think that providing all these extra niceties and polish should be table stakes. I don't agree with any of that, but I kinda see how people could get there.
I think most people fall in the former camp, it's completely fine to politely ask for something, but you have to be okay if they refuse. The latter is just pure entitlement.
I'm of the opinion that SNAP and Flatpack are just different Linux distributions and should package their own software like other distros do. Trying to get upstream to build for these is IMHO not appropriate. When upstream starts needing keys and crap to push builds into a central location/store it's gone way too far - you're burdening upstream and for what?
BTW the easiest way to run Solvespace on Windows is to download the single-exe build. Where I work this is easier than using winget because the exe will run without admin privileges while installing from winget requires it.
No, they don't need to do anything. This is open source software, provided at no cost to the user. The user is not owed a damn thing.
Now a maintainer may choose to provide a build or easy-to-use installer, because making things easier for users (which will presumably increase their user base). They might do that because that has value to them, they find it fun an interesting, they want to feel pride that they have a lot of users... etc.
But they don't "need" to do anything.
Not sure why that triggers people.
I think really it's less so about builds and moreso people want easy package management.
It's not strictly required by the definition of open source, but....
A) If you don't provide builds and successful building is more involved then ./configure && make && make install, then you're pretty user-unfriendly.
B) If you aren't providing builds for target platforms then you probably aren't building for target platforms, which means part of your software has zero test coverage. Again, not a requirement, but it's fair for people to count that as a negative.
I used to distribute open source bindings to a commercial+proprietary library. I couldn't provide builds because I didn't have a distribution right to the proprietary license, even though I could test it on my own copy.
These days I'm having a tough time providing a build for macOS because my Python extension uses OpenMP, and there are several different ways to get OpenMP for that OS. See https://pypackaging-native.github.io/key-issues/native-depen... for details, including how PyTorch vendors Intel's libiomp while Scikit-learn vendors clang's libomp or GNU's libgomp.
Rather than deal with that mess, I provide source, and test with libgomp.
This QT version or that? Hunt down some weird dependency. Find that that dependency clashes with a more recent version, but you can't downgrade. Oh, oops your app depends on a quirk in glibc v x but your system only has v y so now you have to figure out how to run two different glibc's without conflicting with each other, and better not make a mistake during that installation or your system may never boot again.
Complex software can be quite a pain to build properly, more-so if you want to target multiple different architectures or operating systems.
But it is required by Free Software licenses. GPLv2 §3[0]:
> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
GPLv3 §1[1]:
> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
If you are distributing someone else's GPL code, then you must comply with the license and provide build scripts etc.
If you choose to release some code under the GPL that you yourself have written, but do not feel like even writing a Makefile, that's totally fine.
I mean, yes, that's technically correct. But I'm not sure how useful it is? What is it adding to the discussion?
The holder can change licencing for new versions of the software afterall