[HN Gopher] Open Source Doesn't Require Providing Builds
___________________________________________________________________
Open Source Doesn't Require Providing Builds
Author : mroche
Score : 24 points
Date : 2024-01-22 19:46 UTC (3 hours ago)
(HTM) web link (codeengineered.com)
(TXT) w3m dump (codeengineered.com)
| _whiteCaps_ wrote:
| I feel like such a greybeard now... I remember when source code
| was the _only_ way to get software. A pre-built binary? Luxury!
| IshKebab wrote:
| You mean that 11 month period between September 1991 when Linux
| was first released and August 1992 when the SLS distro was
| released?
| yjftsjthsd-h wrote:
| Open source did not begin with Linux, and the existence of
| Linux distros did not mean that everything a user wanted had
| binary packages available.
| ok123456 wrote:
| No. Most open-source packages that weren't universal enough
| to warrant a package often just gave you a c program with the
| Autotools scripts to build it.
|
| 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.
| dunham wrote:
| And it often involved a hard-fought battle with the internals
| of a configure script.
| kwhitefoot wrote:
| A proper configure script should do all that battling for
| you. At least it did when I needed Emacs on a Dec Alpha
| machine. I just did ./configure, make, and make install and
| everything worked.
| bluish29 wrote:
| I would trust a build coming from the upstream project more than
| individual build efforts by people outside the upstream. It
| usually make it more more organized and do help people who wants
| a quick trial ( I wouldn't like having to build each thing I want
| to try). Also people keeping up with updates is a problem when
| you provide the builds. Imagine having to keep up with manually
| build 20 software/packages every couple of weeks.
|
| Yes, we know it is mot requirement. But it is nice and convention
| to do.
| tetris11 wrote:
| If it's reproducible binaries though, and all the various build
| hashes match, what's the issue?
| rezonant wrote:
| I think this sort of verification being available is
| exceedingly rare, especially for builds that statically link
| dependencies.
| orblivion wrote:
| I prefer builds from repositories I trust. Lots of stuff
| happily makes it into the Debian repos. So I guess I'm kind of
| the opposite.
| Ferret7446 wrote:
| I hope you don't use a Linux distribution then. 99% of packages
| of 99% of distros are built by the distro (or a parent, e.g.,
| using Debian repos) and not the upstream source. In fact,
| getting builds directly from upstream is the exception rather
| than the norm, usually used for more niche software that isn't
| shipped by distros (although it is getting more prevalent with
| Flatpak).
| torstenvl wrote:
| Ehhhh... the makefile or AC/AM, which is to say the build
| process, has long been considered part of the source code.
|
| 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.
| eesmith wrote:
| Even Makefile / autoconfig / automake can be user-unfriendly in
| the face of dependencies.
|
| 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.
| jacquesm wrote:
| Especially for user facing (so, UI based) software it
| definitely isn't as easy as .configure && make && make install
| for a very large number of packets.
|
| 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.
| theLiminator wrote:
| I'm pretty happy without builds in ecosystems that compile from
| source with appropriate package managers (go, rust, etc.).
|
| I think really it's less so about builds and moreso people want
| easy package management.
| chacham15 wrote:
| The title as written is obviously true. Obviously any project can
| be "open source" with or without builds. There is no requirement
| that "open source" even compiles! The real issue here is: "is it
| better for the project to provide builds?" and I think that the
| answer is almost certainly yes even if for nothing else other
| than the same reason as "should the project compile?" Now, as
| with all "good things" there are questions of whether its better
| to put effort into this good thing vs that good thing and that is
| a fair discussion, but having the project deliver builds is
| almost certainly "a good thing."
| kwhitefoot wrote:
| If you can't build it then in what sense can you be said to
| have obtained the source code to the application? How can you
| be sure that the code that you have obtained is even related to
| that application?
| zanecodes wrote:
| ...which would be fine, if builds were trivially reproducible (a
| la Nix). Many projects are quite a pain to build, to the point
| where I and probably many others have given up on trying to
| contribute to them.
| rezonant wrote:
| Chromium and its components like libwebrtc are extremely
| difficult to build correctly.
| steveklabnik wrote:
| I have long thought that what the broader zeitgeist considers
| "open source" has diverged significantly from the OSI definition.
| Many don't even really know it exists, much less consider it.
| This aspect is one of them. The author is absolutely right that
| it does not, but I think many people's expectation of a modern
| open source project is that it provides them.
| eesmith wrote:
| Agreed. I think most people think an open source project means
| there is also a public repository, a public issue/bug tracker
| which is generally open for anyone to participate, responsive
| developers handling those issues in a respectful and
| "professional" manner, and as mentioned, pre-compiled builds
| for the three main OS families, and likely more specialized
| builds as well.
|
| 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?
| steveklabnik wrote:
| I think you're right, but a lot of these things are dependent
| on how large of a project it is. The highest order bit is
| some sort of open, democratic-ish (at least nominally)
| governance and/or acceptance of patches from outside of the
| team, I think. It starts with "public issue tracker and
| responsive, professional developers" and then grows from
| there.
| massysett wrote:
| I'm not disagreeing with you. I just think it's amazing that
| people expect ANYTHING from stuff provided to them for free.
|
| 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?
| fghorow wrote:
| Respectfully, I disagree with the OP.
|
| 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.)
| rezonant wrote:
| Sounds like their intricate build process is in service of
| their business model. Pretty crappy thing to do.
| notfried wrote:
| Why no names? I am curious to see the product and how they are
| positioning their business model. I haven't seen something like
| this before.
| fghorow wrote:
| It's one of the (several) forks of Vyatta...
| KAMSPioneer wrote:
| Sounds exactly like VyOS, and GP said it is a fork of Vyatta,
| which fits the bill.
|
| I've not used VyOS in recent years, but their pricing
| structure does seem designed to convert users to customers.
| fghorow wrote:
| Yep. Got it in one...
| yjftsjthsd-h wrote:
| I'm not sure that I'm hearing the disagreement. You want stable
| binaries without paying anything, which I understand but that's
| not an open source thing. The only way I could see it being an
| open source issue is if the build steps they provide to the
| community are different than what they actually like
| internally, and even then you're really hedging on a particular
| definition of the preferred form for modification clause that I
| think the GPL has.
| poulsbohemian wrote:
| So for the uninformed (ie: me), what's so great about this
| router distribution relative to other options that you are
| willing to jump through so many hoops to use it?
| phkahler wrote:
| The general public doesn't have a clue how to build software. If
| that is even remotely part of your target audience, you need to
| provide a build or even an installer.
|
| 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.
| lnxg33k1 wrote:
| People behaves entitled, news at 9.
|
| 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
| Ferret7446 wrote:
| Reading some of the comments here, this is only a significant
| point if your language/tooling makes building non-trivial (and/or
| slow). For example, for Go it is insignificant whether the source
| project provides builds because building is so straightforward,
| fast, and even cross-platform. A lot of Go tools don't ship
| builds because you can just `go install` and be faster than
| navigating a web UI, clicking a Download link, and saving it into
| your PATH.
| jacquesm wrote:
| Open Source: you get to see the code, and you are allowed to
| modify and redistribute it. That's it, everything else is icing
| on the cake and be happy because with closed source you wouldn't
| have any of that.
___________________________________________________________________
(page generated 2024-01-22 23:00 UTC)