12 ms·

Open Source Doesn't Require Providing Builds

39 points by mroche 3y ago

theLiminator 3y ago
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.
_whiteCaps_ 3y ago
I feel like such a greybeard now... I remember when source code was the only way to get software. A pre-built binary? Luxury!
- dunham 3y ago
  And it often involved a hard-fought battle with the internals of a configure script.
  - kwhitefoot 3y ago
    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.
- IshKebab 3y ago
  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 3y ago
    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.
    - IshKebab 3y ago
      Ah I misread - thought he said Linux software.
      - yjftsjthsd-h 3y ago
        Fair enough
  - ok123456 3y ago
    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.
bluish29 3y ago
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 3y ago
  If it's reproducible binaries though, and all the various build hashes match, what's the issue?
  - rezonant 3y ago
    I think this sort of verification being available is exceedingly rare, especially for builds that statically link dependencies.
- orblivion 3y ago
  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 3y ago
  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 3y ago
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 3y ago
  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-dependencies/blas_openmp/ 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 3y ago
  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.
- Karellen 3y ago
  > the build process [...] It's not strictly required by the definition of open source, but.... 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. [0] https://www.gnu.org/licenses/gpl-2.0.html https://www.gnu.org/licenses/gpl-2.0.html [1] https://www.gnu.org/licenses/gpl-3.0.html https://www.gnu.org/licenses/gpl-3.0.html
zanecodes 3y ago
...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 3y ago
  Chromium and its components like libwebrtc are extremely difficult to build correctly.
  - bfrog 3y ago
    that's just like everything else that comes from google
chacham15 3y ago
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 3y ago
  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?
  - krisoft 3y ago
    Not everything is an application. 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.
    - kwhitefoot 3y ago
      You;ve moved the goal posts, the point was that a lot of projects don't supply the make files or a proper list of required build tools in the first place.
steveklabnik 3y ago
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 3y ago
  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 3y ago
    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 3y ago
  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?
  - wakawaka28 3y ago
    [dead]
fghorow 3y ago
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 3y ago
  Sounds like their intricate build process is in service of their business model. Pretty crappy thing to do.
  - inemesitaffia 3y ago
    How so? Open source means customers get source. You're not customer so why would you get the product itself( the product isn't the source)
    - rezonant 3y ago
      That's not what open source itself means, no. Open source means everyone gets source, not only customers. 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.
phkahler 3y ago
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.
- kelnos 3y ago
  > you need 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.
  - phkahler 3y ago
    That's why I qualified it. If you want the general public to use your software, you need to make it easy for them or they won't. Otherwise you're just as entitled as those demanding things of developers - expecting others to do something for them. If you don't care who uses it or not then you don't need to do anything for other people. Not sure why that triggers people.
Ferret7446 3y ago
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.
- jeroenhd 3y ago
  "You can just go install" is what I read a lot, but installing Go can be quite a pain. It's also not exactly clear that you need to run "go install" from a source code dump, which many Go projects seem to come with. 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.
- cpuguy83 3y ago
  Simple go programs are simple to compile.
lnxg33k1 3y ago
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
jacquesm 3y ago
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.
- deleted 3y ago
  [deleted]
- kelnos 3y ago
  Yep, exactly. The level of entitlement some commenters here seem to have is appalling. The project maintainers don't owe anyone free labor. 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.
  - jacquesm 3y ago
    It's insane. Somehow access to the code has transformed into '24x7 unpaid unlimited support, direct influence on the roadmap, the right to bitch and moan about everything that doesn't quite work the way the recipient needs and can I have a pony'. 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.
    - kelnos 3y ago
      Yep, it's a really disturbing trend in people's attitudes. 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.
wakawaka28 3y ago
[dead]

39 points by mroche 3y ago

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.

_whiteCaps_ 3y ago

I feel like such a greybeard now... I remember when source code was the only way to get software. A pre-built binary? Luxury!

dunham 3y ago
And it often involved a hard-fought battle with the internals of a configure script.
- kwhitefoot 3y ago
  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.
IshKebab 3y ago
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 3y ago
  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.
  - IshKebab 3y ago
    Ah I misread - thought he said Linux software.
    - yjftsjthsd-h 3y ago
      Fair enough
- ok123456 3y ago
  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.

bluish29 3y ago

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 3y ago
If it's reproducible binaries though, and all the various build hashes match, what's the issue?
- rezonant 3y ago
  I think this sort of verification being available is exceedingly rare, especially for builds that statically link dependencies.
orblivion 3y ago
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 3y ago
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 3y ago

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 3y ago
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-dependencies/blas_openmp/ 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 3y ago
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.
Karellen 3y ago
> the build process [...] It's not strictly required by the definition of open source, but.... 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. [0] https://www.gnu.org/licenses/gpl-2.0.html https://www.gnu.org/licenses/gpl-2.0.html [1] https://www.gnu.org/licenses/gpl-3.0.html https://www.gnu.org/licenses/gpl-3.0.html

zanecodes 3y ago

...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 3y ago
Chromium and its components like libwebrtc are extremely difficult to build correctly.
- bfrog 3y ago
  that's just like everything else that comes from google

chacham15 3y ago

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 3y ago
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?
- krisoft 3y ago
  Not everything is an application. 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.
  - kwhitefoot 3y ago
    You;ve moved the goal posts, the point was that a lot of projects don't supply the make files or a proper list of required build tools in the first place.

steveklabnik 3y ago

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 3y ago
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 3y ago
  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 3y ago
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?
- wakawaka28 3y ago
  [dead]

fghorow 3y ago

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 3y ago
Sounds like their intricate build process is in service of their business model. Pretty crappy thing to do.
- inemesitaffia 3y ago
  How so? Open source means customers get source. You're not customer so why would you get the product itself( the product isn't the source)
  - rezonant 3y ago
    That's not what open source itself means, no. Open source means everyone gets source, not only customers. 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.

phkahler 3y ago

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.

kelnos 3y ago
> you need 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.
- phkahler 3y ago
  That's why I qualified it. If you want the general public to use your software, you need to make it easy for them or they won't. Otherwise you're just as entitled as those demanding things of developers - expecting others to do something for them. If you don't care who uses it or not then you don't need to do anything for other people. Not sure why that triggers people.

Ferret7446 3y ago

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.

jeroenhd 3y ago
"You can just go install" is what I read a lot, but installing Go can be quite a pain. It's also not exactly clear that you need to run "go install" from a source code dump, which many Go projects seem to come with. 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.
cpuguy83 3y ago
Simple go programs are simple to compile.

lnxg33k1 3y ago

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

jacquesm 3y ago

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.

deleted 3y ago
[deleted]
kelnos 3y ago
Yep, exactly. The level of entitlement some commenters here seem to have is appalling. The project maintainers don't owe anyone free labor. 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.
- jacquesm 3y ago
  It's insane. Somehow access to the code has transformed into '24x7 unpaid unlimited support, direct influence on the roadmap, the right to bitch and moan about everything that doesn't quite work the way the recipient needs and can I have a pony'. 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.
  - kelnos 3y ago
    Yep, it's a really disturbing trend in people's attitudes. 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.

wakawaka28 3y ago

[dead]