6 ms·

This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened. Don't build FOSS for others.

This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened. Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time. Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.

mikepurvis 4y ago
Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable. These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware. In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.
- geerlingguy 4y ago
  Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.
  - mikepurvis 4y ago
    I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
    - wallmountedtv 4y ago
      I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.
      - mikepurvis 4y ago
        Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.
MikePlacid 4y ago
- nomdep 4y ago
  Never promise anything to people using your code. Even if they are paying, unless it is in a contract.
  - pfortuny 4y ago
    Yep. The “this software is distributed as is, with no guarantees…” is essential in any kind of freelance open source development. That sentence does not appear in the BSD licenses and I deem that a mistake.
    - sarnowski 4y ago
      Every BSD license has this, which is for that purpose: THIS SOFTWARE IS PROVIDED „AS IS“ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  - MikePlacid 4y ago
    > Never promise anything to people using your code. Even if they are paying, unless it is in a contract. “Never” is a very strong word. What is your recommendation based upon, exactly? This is my code. It costs me nothing to tell people my future plans with the code. It costs me nothing to tell people that my plans are most probably off. But it will gain people something - they would be able to plan for the future better. “Politeness costs nothing and gains everything” - is a better theorem (than yours one). I would rather tell it as: politeness usually costs nothing and gains at least something, but that’s just an engineer correcting a salesman’s statement.
    - nomdep 4y ago
      A promised feature feels like something you already have, and just need to wait for a little bit. But your plans can change. Maybe you change your priorities, maybe you discover that a feature is harder to implement than what you tought and you must reduce its scope. Or maybe you realize it was a bad idea after all and decide to implement a different feature. If you have promise the original feature, instead of happy users for the improvement, some of them will be angry because of what you "took from them". That's why I think the real politeness is to never promise nothing concrete until you are actually ready to ship it.
bombolo 4y ago
> Hard to fork and maintain my own version apt-get source xxxx put patch in debian/patches dch --increase dpkg-buildpackage. Copy the patch and rebuild next time a new version comes out.
- robertlagrant 4y ago
  Creating bridges that allow Apt to become the overarching package manager for all sorts of language-specific packages would be extremely interesting.
  - still_grokking 4y ago
    $ apt rdepends debhelper
  - bombolo 4y ago
    Most languages have that already.
account42 4y ago
> Hard to start with a package and float my own changes. Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches https://wiki.gentoo.org/wiki//etc/portage/patches

mikepurvis 4y ago

Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable. These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware. In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.

geerlingguy 4y ago
Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.
- mikepurvis 4y ago
  I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
  - wallmountedtv 4y ago
    I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.
    - mikepurvis 4y ago
      Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.

MikePlacid 4y ago

nomdep 4y ago
Never promise anything to people using your code. Even if they are paying, unless it is in a contract.
- pfortuny 4y ago
  Yep. The “this software is distributed as is, with no guarantees…” is essential in any kind of freelance open source development. That sentence does not appear in the BSD licenses and I deem that a mistake.
  - sarnowski 4y ago
    Every BSD license has this, which is for that purpose: THIS SOFTWARE IS PROVIDED „AS IS“ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- MikePlacid 4y ago
  > Never promise anything to people using your code. Even if they are paying, unless it is in a contract. “Never” is a very strong word. What is your recommendation based upon, exactly? This is my code. It costs me nothing to tell people my future plans with the code. It costs me nothing to tell people that my plans are most probably off. But it will gain people something - they would be able to plan for the future better. “Politeness costs nothing and gains everything” - is a better theorem (than yours one). I would rather tell it as: politeness usually costs nothing and gains at least something, but that’s just an engineer correcting a salesman’s statement.
  - nomdep 4y ago
    A promised feature feels like something you already have, and just need to wait for a little bit. But your plans can change. Maybe you change your priorities, maybe you discover that a feature is harder to implement than what you tought and you must reduce its scope. Or maybe you realize it was a bad idea after all and decide to implement a different feature. If you have promise the original feature, instead of happy users for the improvement, some of them will be angry because of what you "took from them". That's why I think the real politeness is to never promise nothing concrete until you are actually ready to ship it.

bombolo 4y ago

> Hard to fork and maintain my own version apt-get source xxxx put patch in debian/patches dch --increase dpkg-buildpackage. Copy the patch and rebuild next time a new version comes out.

robertlagrant 4y ago
Creating bridges that allow Apt to become the overarching package manager for all sorts of language-specific packages would be extremely interesting.
- still_grokking 4y ago
  $ apt rdepends debhelper
- bombolo 4y ago
  Most languages have that already.

account42 4y ago

> Hard to start with a package and float my own changes. Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches https://wiki.gentoo.org/wiki//etc/portage/patches