10 ms·

Do not ship work in progress: An open letter

161 points by sellweek 4y ago

mittermayr 4y ago
Funny how I was instantly triggered as a SaaS maker by the title, ready to unroll in the comments and then quickly realized upon reading that I am not the audience here and the title does make a lot of sense for the intended audience :) Unexpected self-calibration completed. Nice.
- bin_bash 4y ago
  Same, I thought it was going to be an argument about MVPs
- antonvs 4y ago
  Many startups wouldn't ever be able to get started under a restriction like that.
  - eastbound 4y ago
    “If you’re not ashamed of your first version, you shipped too late.” Reid Hoffman
    - systemvoltage 4y ago
      This is bullshit. There is a big difference between: 1) Shipping low features but high quality SaaS aap: OK 2) Shipping low quality services with lots of features that are buggy: NOT OK From a customer standpoint, I reject half-baked SaaS services that reek with lack of quality control. If you are ashamed of your first version because of bugs, stop and fix those. If you're ashamed of how minimal your first app is? That's fine. Make sure those features are high quality and work as intended.
      - antonvs 4y ago
        Spoken like a developer, not a businessperson. The real world is a lot more complicated. As Rumsfeld put it, "You go to war with the army you have, not the army you might want or wish to have at a later time." A startup might have a product with a promising and unique core feature, but still have many other features that are buggy. It's common for startups to be overambitious, and that often manifests as buggy features. Startups like this will often have a high churn rate with early customers and trials. But that changes over time as they get experience with which features and which issues matter. If you want to kill a new business quickly, "stop and fix" the bugs in your first version. The problem is, your first version may very well not be the one with the best product/market fit, and you just wasted your precious investment money, time, and resources fixing bugs that ultimately won't matter.
- remram 4y ago
  To be honest this is a very click-baity title that doesn't have the context to make it a truth. A lot of us probably came here expecting something else, like you. A better title would be "Do not ship someone else's work in progress"
blueflow 4y ago
Would it fix the problem to develop with a more restrictive license, and only license the releases with a more permissive license?
- andix 4y ago
  Interesting thought :D But it would probably create even more legal issues and also risks. A lot of people don’t use software, that has a non-standard way of licensing (like MIT, BSD, Apache, GPL). Just because there is a risk that you step into a legal trap.
  - jsty 4y ago
    If only the WIP commits were non-Free then relicensed to Free for each release, then the legal uncertainty would probably have the desired effect - no packager / distro worth their salt would touch any non-release with a barge pole. Such an unorthodox approach would risk scaring them off completely though. In a roundabout way it's pretty much trying to re-invent the trademark system (ie. "don't distribute this code and call it MyProject without it being an authorised release"). Quite frankly far easier to just get a trademark if that's the desired effect.
    - mschuster91 4y ago
      > Quite frankly far easier to just get a trademark if that's the desired effect. Trademarks cost serious upfront money - Germany alone is 290€ [1], EU-wide 850€ [2], the US 250$ [3] and worldwide is a hot mess [4]. Additionally, it seems like you need a lawyer in the US to handle the process if you're not an US resident, and you have to renew them every couple of years and not forget to tell the patent/trademark office of address changes. Not everyone is willing to put up that much money and effort for an open-source project that won't generate any income. Additionally, trademarks usually force the holder to publicly register their name and address, which is simply not a good idea at all for many persons - trolls, spammers and outright criminals can and will use every bit of information they get to cause harm. And for collectives that run an open-source project, trademarks will be yet another issue - what to do when the holder of the trademark dies or disappears, or when they get into some sort of conflict? [1] https://www.dpma.de/marken/ https://www.dpma.de/marken/ [2] https://euipo.europa.eu/ohimportal/en/fees-and-payments https://euipo.europa.eu/ohimportal/en/fees-and-payments [3] https://www.uspto.gov/trademarks/basics/how-much-does-it-cost https://www.uspto.gov/trademarks/basics/how-much-does-it-cos... [3] https://www.wipo.int/madrid/en/ https://www.wipo.int/madrid/en/
kop316 4y ago
For some additional context: https://blog.brixit.nl/why-i-left-pine64/ https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 https://news.ycombinator.com/item?id=32494659 > Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken versions of software and pointing to the developers for support. Which is why https://dont-ship.it/ https://dont-ship.it/ was started.
- rob74 4y ago
  So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?
  - ddevault 4y ago
    Distributions like Manjaro should change their behavior and quit shipping unfinished patches.
    - WesolyKubeczek 4y ago
      What if the whole point is about shipping unfinished patches? But also this should mean that the buck stops with the distribution, not with the developers.
      - mannykannot 4y ago
        What is the use case for shipping unfinished patches?
        viraptor 4y ago
        Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/development/tools/rbspy/default.nix#L25 https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch. It's a cost/benefit calculation for the maintainers.
quickthrower2 4y ago
That should be common sense. Shrug.
bin_bash 4y ago
I love those "under construction" images at the bottom. Takes me back to the 90's.
O__________O 4y ago
Title is click-bait, it’s about a very, very narrow subset of the topic — that is Linux patches.
- Rackedup 4y ago
  At least they let you know in the first paragraph but I agree even if it doesn't apply only to the Linux kernel.
- pessimizer 4y ago
  If an article in Stamp Collectors Weekly has the headline "The Market is Getting Irrational," is it clickbait for that article to be about the stamp market? It's weird to call someone's site about Linux patches clickbait because it's not about shipping half-finished furniture.
  - O__________O 4y ago
    To me anything that intentionally misleads or overly generalize a topic which might be clearly and specifically addressed is click-bait by definition. Author does not even mention that the post is specifically related to Pine64’s dependency on the Manjaro distro; a dependency that they not only self selected, but are funding. If they have such a major issue, solution is obvious, either change distros or fork it and only allow patches they are happy with into their ecosystem; not post a petition, of which so far only 16 people have signed since it was posted in June. Also, worth noting that Pine64 originally was built on Ubuntu, which has long-term releases, which is basically what author is asking for.
WesolyKubeczek 4y ago
But then again, free and open source licenses enable everyone to do any modifications for any purpose whatsoever. That's the whole point. I would like it if the developers quit being patronizing towards people exercising their rights under those licenses. Yes, don't ship it, don't theme my app. We all heard you. Some people choose to not care, and that's okay. Those same licenses also disclaim any warranty, so the buck stops with whomever applies random patches and takes money for it. In this case, the phone manufacturer shipping OS images. The phone manufacturer can duke it out with Manjaro, of course, and Manjaro folks can tell them to go pound sand and use Debian stable. This is well before upstream should even notice a shadow of kerfuffle happening. The developers have come up with a multitude of ideas on how to be passive aggressive towards anyone either trying to contribute or submit an issue, stalebot and radio silence being only two of them, so I'm wondering why they just won't apply those techniques this time.
- Etheryte 4y ago
  This is completely missing the forest for the trees. Just because something is not illegal doesn't mean it's a good idea. When a distro maintainer includes half baked patches for some third party software and the end user then has an issue with it, you can be sure they're gonna reach out to the software maintainers, not to the distro. By the time the back and forth helps everyone figure out that the problem is the version the distro packaged you've created a lot of useless noise and wasted plenty of time.
- simiones 4y ago
  The problem is something like this: you develop packageA. A user of distroB is installing pacakgeA from distroB latest, and packageA is not working for them. distroB maintainers tell them to go ask packageA about the bug. So, the user comes and bothers packageA about this issue - even though packageA had no intention of distributing this in-progress version to users. Now, of course, no one here is doing anything illegal. But, everything would be better for everyone if distroB, instead of taking packageA@master had taken packageA@1.0.1 or whatever the latest release is: better working software for distroB users, less support work (bug triage etc) for distroB, less work for packageA maintainers. Since this is ultimately a social issue, I think an open letter seeking to convince the people involved to think about it and modify their behavior is the best way of going about improving this for everyone. Now, it may well be that the maintainers of distroB have valid reasons not to change their behavior and ignore this letter: all fine. Not saying we should tar and feather them, in any way shape or form. But if this is maybe a fixable problem, why not try to fix it?
jstanley 4y ago
> In short: when a project is being actively developed, tagged releases are the only safe option to ship to users. If this is such a problem that people need to be warned about it, why not just keep development on branches and make sure master is always stable?
- MartijnBraam 4y ago
  That wouldn't help because they're not picking master to ship, they're picking mailing list patches and unmerged or rejected Gitlab merge requests directly. If only they would ship master, that's at least somewhat sane.
  - j16sdiz 4y ago
    The page is missing all these contexts. It don’t make much sense on its own
natch 4y ago
So if there’s a patch that fixes a devastating bug then distros should ship with the bug, got it. Or reach out to the developer who does not respond to email (who is likely also not a signer of this open letter and who may or may not agree with it). Multiply this (futile) reach-out step times however many developers are involved in touching any code of any project being shipped during any if the multiple days, weeks, or months between releases. Which is probably hundreds of unanswered emails. Mmmkay.
- kirbyfan64sos 4y ago
  The page literally addresses this: > We thank all the distribution package maintainers for backporting patches that improve security, fix bugs, etc. who coordinate with upstream. Often times this means creating or pulling patches to fix issues with inactive/abandoned/unresponsive upstream projects. These distribution package maintainers are doing a tremendous job and their work is not the subject of this letter. > This letter wants to address the cases where actively-developed features, huge changes, etc. of active upstream projects are being included without the knowledge of the project maintainers or end users.
  - natch 4y ago
    I wouldn’t say it addresses it so much as it acknowledges it as an issue without offering a workable solution.
    - pessimizer 4y ago
      What's a more workable solution for urgent patches than not including them in the request to "not ship work in progress."
      - natch 4y ago
        If the developers themselves don’t “ship” changes to any copy of their repository outside of their own privately accessible space, the (perceived from their perspective) problem is solved.
jwildeboer 4y ago
Without concrete examples of good v bad behaviour it’s a lonely call in the void, IMHO. Without a clear commitment to solid versioning, where it is clear what is considered ready and stable v WIP it also doesn’t really help. Good will on all sides depends on understanding and communicating. This is a task for all.
matkoniecz 4y ago
> when a project is being actively developed, tagged releases are the only safe option to ship to users. Not always. https://github.com/clementine-player/Clementine https://github.com/clementine-player/Clementine is a great software, being developed but for some reason without release since 2016. Last release does not work anymore, shipping master branch works.
- dewey 4y ago
  The author isn't saying that it's the only possible way to ship software to users, he's saying that it's the only safe / good option. Just because some project without a proper release cycle does it doesn't make this statement any less true.
voydik 4y ago
Mostly agree. I recently caught up with Peter from Journey.io for an interview and he mentioned exactly this. Something along the lines of "the era of janky MVPs is over." There's certainly a balance of shipping an MVP and shipping crap. I think if you routinely ship crap, or things that are subpar, for the sake of speed, users will start to associate all of your work with crap.
- droobles 4y ago
  I think maybe I saw it on Indie Hackers but there was a term I liked for this evolution in customer expectations called MAP, Most Awesome Product. While weirdly named, it’s the base product required for potential customers to go, “Wow, that’s awesome we need that.”
speeder 4y ago
This applies even to games. Although it is normal now for games have early access releases, it is becoming common for rushed 1.0 releases and then patching coming later... coupled with a ton of negative reviews, backlash and lost sales. I wonder why publishers don't realize people expect the product to be done when you remove "beta" from its name.
- wongarsu 4y ago
  They see companies which have great success despite consistently shipping broken products for decades (Bethesda), and lots of indies shipping unfinished products through proper expectation management (early access), and think they can get away with it. Often there's also great pressure to hit particular time windows (e.g. release October-December to get Chrismas sales, release live at a trade show, avoid releasing just before or after a more popular title in the same genre, etc)
remram 4y ago
I wonder if this could be solved with license terms. Popular, OSI-approved licenses include clauses like "Neither the name of the <copyright holder> nor the names of its contributors may be used to endorse or promote products derived from this software" (BSD) or restrictions on the use of the original name (see Firefox/Iceweasel drama). If you put in a clause like "You may not keep the software's name or support URL unless distributing an officially-released version", perhaps it would still be open-source as per OSI, and address those distribution issues? It's easy enough for distributors to patch in their own support mailing-list...
- hedora 4y ago
  I think you could just assert that unmerged PR's have the following license: "All Rights Reserved"
  - remram 4y ago
    This won't work with most licenses, if you don't own copyright over the totality of trunk. The PR is definitely a derivative of the trunk...
pledess 4y ago
Although "not ship work in progress" has many advantages, it interferes with "staying very close to HEAD of our dependencies" as discussed in the https://aboodman.medium.com/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b https://aboodman.medium.com/in-march-2011-i-drafted-an-artic... post. In other words, if your code is being consumed by another project that has extremely good test coverage, and your HEAD changes, then they can manage the risk of proceeding - even if they have no a priori idea of whether your latest commit is for a standalone improvement, or whether your latest commit is disruptive unless the entire work-in-progress is consumed together. They may find that managing this risk is easier than managing the risk of "huge chunks of new code suddenly showing up."
- TeeMassive 4y ago
  Solution seems to be features toggles, but then that means you have a somewhat complete product to begin with; and it being mature enough to support feature toggles.
purpleblue 4y ago
I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable, ie. midway through feature development. I vehemently pushed back, saying that it would be disruptive to our customers since the feature wasn't fully finished and it would slow us down, because we would need to change the order in which we would do development since customers expect a certain level of quality. I also said that any timelines after customers were onboarded were at risk, because if things were buggy, which they probably were since the feature wasn't finished yet, it would mean we would have to jump on them since they were our biggest customers. These all fell on deaf ears because they thought it would be important to get early feedback from our customers. I told them we could demo it, but we shouldn't onboard them. Again, they refused to listen. Things ended up being exactly as you expected, and I quit the job so that I didn't have to deal with this PM any more.
- lopkeny12ko 4y ago
  What does this anecdote have anything to do with the article?
- donmaq 4y ago
  > I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable FWIW, I recognize it's fun to target PMs for ignoring technical constraints & carrying water for marketing... but for many PMs (in USA at least), they roll up to Marketing dept, rather than Eng. So while it can seem PMs are (willfully?) technically Invincibly ignorant by default, their bosses are worse. The best way to 'manage' your PM is help them build the biz case for your position. Eg "reduce risk of $XX loss" from bugs, opty costs, network effects of customer losing faith in your product. Plus I've found the "walk before you can run" argument works: they want to expand customer excitement by showing bright/shiny/new things. Promise them an even faster cadence of new things, after they give you time to get the fundamentals deployed.
zzo38computer 4y ago
It is sensible; it is better to ship released versions in the package manager, instead of unreleased versions, at least by default. (If the package manager does not have the capability to distinguish in this way, then a user who wishes to use unreleased versions could compile it by themself instead.) Unfortunately, some projects do not have any tagged releases (or, at least, doesn't have any yet), and might still be stable. I intend to add tagged releases to my "Free Hero Mesh" project eventually, in order to avoid this problem, that you can clearly have a released and tagged, with version numbers. A distribution may need to patch bugs or other things in the software, to work with the distribution. This is OK, but they should probably mark this in some way, such as a nonstandard version number (e.g. "1.5.2.debian.1") or a different name. Possibly such nonstandard version numbers should also be included in the software itself if it has the capability to display its own version number, and not limited to the package manager. Sometimes there is a separate list of patches applied than the version number; this might also be usable (instead of or in addition to the version number).

161 points by sellweek 4y ago

Funny how I was instantly triggered as a SaaS maker by the title, ready to unroll in the comments and then quickly realized upon reading that I am not the audience here and the title does make a lot of sense for the intended audience :) Unexpected self-calibration completed. Nice.

bin_bash 4y ago
Same, I thought it was going to be an argument about MVPs
antonvs 4y ago
Many startups wouldn't ever be able to get started under a restriction like that.
- eastbound 4y ago
  “If you’re not ashamed of your first version, you shipped too late.” Reid Hoffman
  - systemvoltage 4y ago
    This is bullshit. There is a big difference between: 1) Shipping low features but high quality SaaS aap: OK 2) Shipping low quality services with lots of features that are buggy: NOT OK From a customer standpoint, I reject half-baked SaaS services that reek with lack of quality control. If you are ashamed of your first version because of bugs, stop and fix those. If you're ashamed of how minimal your first app is? That's fine. Make sure those features are high quality and work as intended.
    - antonvs 4y ago
      Spoken like a developer, not a businessperson. The real world is a lot more complicated. As Rumsfeld put it, "You go to war with the army you have, not the army you might want or wish to have at a later time." A startup might have a product with a promising and unique core feature, but still have many other features that are buggy. It's common for startups to be overambitious, and that often manifests as buggy features. Startups like this will often have a high churn rate with early customers and trials. But that changes over time as they get experience with which features and which issues matter. If you want to kill a new business quickly, "stop and fix" the bugs in your first version. The problem is, your first version may very well not be the one with the best product/market fit, and you just wasted your precious investment money, time, and resources fixing bugs that ultimately won't matter.
remram 4y ago
To be honest this is a very click-baity title that doesn't have the context to make it a truth. A lot of us probably came here expecting something else, like you. A better title would be "Do not ship someone else's work in progress"

blueflow 4y ago

Would it fix the problem to develop with a more restrictive license, and only license the releases with a more permissive license?

andix 4y ago
Interesting thought :D But it would probably create even more legal issues and also risks. A lot of people don’t use software, that has a non-standard way of licensing (like MIT, BSD, Apache, GPL). Just because there is a risk that you step into a legal trap.
- jsty 4y ago
  If only the WIP commits were non-Free then relicensed to Free for each release, then the legal uncertainty would probably have the desired effect - no packager / distro worth their salt would touch any non-release with a barge pole. Such an unorthodox approach would risk scaring them off completely though. In a roundabout way it's pretty much trying to re-invent the trademark system (ie. "don't distribute this code and call it MyProject without it being an authorised release"). Quite frankly far easier to just get a trademark if that's the desired effect.
  - mschuster91 4y ago
    > Quite frankly far easier to just get a trademark if that's the desired effect. Trademarks cost serious upfront money - Germany alone is 290€ [1], EU-wide 850€ [2], the US 250$ [3] and worldwide is a hot mess [4]. Additionally, it seems like you need a lawyer in the US to handle the process if you're not an US resident, and you have to renew them every couple of years and not forget to tell the patent/trademark office of address changes. Not everyone is willing to put up that much money and effort for an open-source project that won't generate any income. Additionally, trademarks usually force the holder to publicly register their name and address, which is simply not a good idea at all for many persons - trolls, spammers and outright criminals can and will use every bit of information they get to cause harm. And for collectives that run an open-source project, trademarks will be yet another issue - what to do when the holder of the trademark dies or disappears, or when they get into some sort of conflict? [1] https://www.dpma.de/marken/ https://www.dpma.de/marken/ [2] https://euipo.europa.eu/ohimportal/en/fees-and-payments https://euipo.europa.eu/ohimportal/en/fees-and-payments [3] https://www.uspto.gov/trademarks/basics/how-much-does-it-cost https://www.uspto.gov/trademarks/basics/how-much-does-it-cos... [3] https://www.wipo.int/madrid/en/ https://www.wipo.int/madrid/en/

kop316 4y ago

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 https://news.ycombinator.com/item?id=32494659 > Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken versions of software and pointing to the developers for support. Which is why https://dont-ship.it/ https://dont-ship.it/ was started.

rob74 4y ago
So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?
- ddevault 4y ago
  Distributions like Manjaro should change their behavior and quit shipping unfinished patches.
  - WesolyKubeczek 4y ago
    What if the whole point is about shipping unfinished patches? But also this should mean that the buck stops with the distribution, not with the developers.
    - mannykannot 4y ago
      What is the use case for shipping unfinished patches?
      - viraptor 4y ago
        Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/development/tools/rbspy/default.nix#L25 https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch. It's a cost/benefit calculation for the maintainers.

quickthrower2 4y ago

That should be common sense. Shrug.

bin_bash 4y ago

I love those "under construction" images at the bottom. Takes me back to the 90's.

O__________O 4y ago

Title is click-bait, it’s about a very, very narrow subset of the topic — that is Linux patches.

Rackedup 4y ago
At least they let you know in the first paragraph but I agree even if it doesn't apply only to the Linux kernel.
pessimizer 4y ago
If an article in Stamp Collectors Weekly has the headline "The Market is Getting Irrational," is it clickbait for that article to be about the stamp market? It's weird to call someone's site about Linux patches clickbait because it's not about shipping half-finished furniture.
- O__________O 4y ago
  To me anything that intentionally misleads or overly generalize a topic which might be clearly and specifically addressed is click-bait by definition. Author does not even mention that the post is specifically related to Pine64’s dependency on the Manjaro distro; a dependency that they not only self selected, but are funding. If they have such a major issue, solution is obvious, either change distros or fork it and only allow patches they are happy with into their ecosystem; not post a petition, of which so far only 16 people have signed since it was posted in June. Also, worth noting that Pine64 originally was built on Ubuntu, which has long-term releases, which is basically what author is asking for.

WesolyKubeczek 4y ago

But then again, free and open source licenses enable everyone to do any modifications for any purpose whatsoever. That's the whole point. I would like it if the developers quit being patronizing towards people exercising their rights under those licenses. Yes, don't ship it, don't theme my app. We all heard you. Some people choose to not care, and that's okay. Those same licenses also disclaim any warranty, so the buck stops with whomever applies random patches and takes money for it. In this case, the phone manufacturer shipping OS images. The phone manufacturer can duke it out with Manjaro, of course, and Manjaro folks can tell them to go pound sand and use Debian stable. This is well before upstream should even notice a shadow of kerfuffle happening. The developers have come up with a multitude of ideas on how to be passive aggressive towards anyone either trying to contribute or submit an issue, stalebot and radio silence being only two of them, so I'm wondering why they just won't apply those techniques this time.

Etheryte 4y ago
This is completely missing the forest for the trees. Just because something is not illegal doesn't mean it's a good idea. When a distro maintainer includes half baked patches for some third party software and the end user then has an issue with it, you can be sure they're gonna reach out to the software maintainers, not to the distro. By the time the back and forth helps everyone figure out that the problem is the version the distro packaged you've created a lot of useless noise and wasted plenty of time.
simiones 4y ago
The problem is something like this: you develop packageA. A user of distroB is installing pacakgeA from distroB latest, and packageA is not working for them. distroB maintainers tell them to go ask packageA about the bug. So, the user comes and bothers packageA about this issue - even though packageA had no intention of distributing this in-progress version to users. Now, of course, no one here is doing anything illegal. But, everything would be better for everyone if distroB, instead of taking packageA@master had taken packageA@1.0.1 or whatever the latest release is: better working software for distroB users, less support work (bug triage etc) for distroB, less work for packageA maintainers. Since this is ultimately a social issue, I think an open letter seeking to convince the people involved to think about it and modify their behavior is the best way of going about improving this for everyone. Now, it may well be that the maintainers of distroB have valid reasons not to change their behavior and ignore this letter: all fine. Not saying we should tar and feather them, in any way shape or form. But if this is maybe a fixable problem, why not try to fix it?

jstanley 4y ago

> In short: when a project is being actively developed, tagged releases are the only safe option to ship to users. If this is such a problem that people need to be warned about it, why not just keep development on branches and make sure master is always stable?

MartijnBraam 4y ago
That wouldn't help because they're not picking master to ship, they're picking mailing list patches and unmerged or rejected Gitlab merge requests directly. If only they would ship master, that's at least somewhat sane.
- j16sdiz 4y ago
  The page is missing all these contexts. It don’t make much sense on its own

natch 4y ago

So if there’s a patch that fixes a devastating bug then distros should ship with the bug, got it. Or reach out to the developer who does not respond to email (who is likely also not a signer of this open letter and who may or may not agree with it). Multiply this (futile) reach-out step times however many developers are involved in touching any code of any project being shipped during any if the multiple days, weeks, or months between releases. Which is probably hundreds of unanswered emails. Mmmkay.

kirbyfan64sos 4y ago
The page literally addresses this: > We thank all the distribution package maintainers for backporting patches that improve security, fix bugs, etc. who coordinate with upstream. Often times this means creating or pulling patches to fix issues with inactive/abandoned/unresponsive upstream projects. These distribution package maintainers are doing a tremendous job and their work is not the subject of this letter. > This letter wants to address the cases where actively-developed features, huge changes, etc. of active upstream projects are being included without the knowledge of the project maintainers or end users.
- natch 4y ago
  I wouldn’t say it addresses it so much as it acknowledges it as an issue without offering a workable solution.
  - pessimizer 4y ago
    What's a more workable solution for urgent patches than not including them in the request to "not ship work in progress."
    - natch 4y ago
      If the developers themselves don’t “ship” changes to any copy of their repository outside of their own privately accessible space, the (perceived from their perspective) problem is solved.

jwildeboer 4y ago

Without concrete examples of good v bad behaviour it’s a lonely call in the void, IMHO. Without a clear commitment to solid versioning, where it is clear what is considered ready and stable v WIP it also doesn’t really help. Good will on all sides depends on understanding and communicating. This is a task for all.

matkoniecz 4y ago

> when a project is being actively developed, tagged releases are the only safe option to ship to users. Not always. https://github.com/clementine-player/Clementine https://github.com/clementine-player/Clementine is a great software, being developed but for some reason without release since 2016. Last release does not work anymore, shipping master branch works.

dewey 4y ago
The author isn't saying that it's the only possible way to ship software to users, he's saying that it's the only safe / good option. Just because some project without a proper release cycle does it doesn't make this statement any less true.

voydik 4y ago

Mostly agree. I recently caught up with Peter from Journey.io for an interview and he mentioned exactly this. Something along the lines of "the era of janky MVPs is over." There's certainly a balance of shipping an MVP and shipping crap. I think if you routinely ship crap, or things that are subpar, for the sake of speed, users will start to associate all of your work with crap.

droobles 4y ago
I think maybe I saw it on Indie Hackers but there was a term I liked for this evolution in customer expectations called MAP, Most Awesome Product. While weirdly named, it’s the base product required for potential customers to go, “Wow, that’s awesome we need that.”

speeder 4y ago

This applies even to games. Although it is normal now for games have early access releases, it is becoming common for rushed 1.0 releases and then patching coming later... coupled with a ton of negative reviews, backlash and lost sales. I wonder why publishers don't realize people expect the product to be done when you remove "beta" from its name.

wongarsu 4y ago
They see companies which have great success despite consistently shipping broken products for decades (Bethesda), and lots of indies shipping unfinished products through proper expectation management (early access), and think they can get away with it. Often there's also great pressure to hit particular time windows (e.g. release October-December to get Chrismas sales, release live at a trade show, avoid releasing just before or after a more popular title in the same genre, etc)

remram 4y ago

I wonder if this could be solved with license terms. Popular, OSI-approved licenses include clauses like "Neither the name of the <copyright holder> nor the names of its contributors may be used to endorse or promote products derived from this software" (BSD) or restrictions on the use of the original name (see Firefox/Iceweasel drama). If you put in a clause like "You may not keep the software's name or support URL unless distributing an officially-released version", perhaps it would still be open-source as per OSI, and address those distribution issues? It's easy enough for distributors to patch in their own support mailing-list...

hedora 4y ago
I think you could just assert that unmerged PR's have the following license: "All Rights Reserved"
- remram 4y ago
  This won't work with most licenses, if you don't own copyright over the totality of trunk. The PR is definitely a derivative of the trunk...

pledess 4y ago

Although "not ship work in progress" has many advantages, it interferes with "staying very close to HEAD of our dependencies" as discussed in the https://aboodman.medium.com/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b https://aboodman.medium.com/in-march-2011-i-drafted-an-artic... post. In other words, if your code is being consumed by another project that has extremely good test coverage, and your HEAD changes, then they can manage the risk of proceeding - even if they have no a priori idea of whether your latest commit is for a standalone improvement, or whether your latest commit is disruptive unless the entire work-in-progress is consumed together. They may find that managing this risk is easier than managing the risk of "huge chunks of new code suddenly showing up."

TeeMassive 4y ago
Solution seems to be features toggles, but then that means you have a somewhat complete product to begin with; and it being mature enough to support feature toggles.

purpleblue 4y ago

I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable, ie. midway through feature development. I vehemently pushed back, saying that it would be disruptive to our customers since the feature wasn't fully finished and it would slow us down, because we would need to change the order in which we would do development since customers expect a certain level of quality. I also said that any timelines after customers were onboarded were at risk, because if things were buggy, which they probably were since the feature wasn't finished yet, it would mean we would have to jump on them since they were our biggest customers. These all fell on deaf ears because they thought it would be important to get early feedback from our customers. I told them we could demo it, but we shouldn't onboard them. Again, they refused to listen. Things ended up being exactly as you expected, and I quit the job so that I didn't have to deal with this PM any more.

lopkeny12ko 4y ago
What does this anecdote have anything to do with the article?
donmaq 4y ago
> I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable FWIW, I recognize it's fun to target PMs for ignoring technical constraints & carrying water for marketing... but for many PMs (in USA at least), they roll up to Marketing dept, rather than Eng. So while it can seem PMs are (willfully?) technically Invincibly ignorant by default, their bosses are worse. The best way to 'manage' your PM is help them build the biz case for your position. Eg "reduce risk of $XX loss" from bugs, opty costs, network effects of customer losing faith in your product. Plus I've found the "walk before you can run" argument works: they want to expand customer excitement by showing bright/shiny/new things. Promise them an even faster cadence of new things, after they give you time to get the fundamentals deployed.

zzo38computer 4y ago

It is sensible; it is better to ship released versions in the package manager, instead of unreleased versions, at least by default. (If the package manager does not have the capability to distinguish in this way, then a user who wishes to use unreleased versions could compile it by themself instead.) Unfortunately, some projects do not have any tagged releases (or, at least, doesn't have any yet), and might still be stable. I intend to add tagged releases to my "Free Hero Mesh" project eventually, in order to avoid this problem, that you can clearly have a released and tagged, with version numbers. A distribution may need to patch bugs or other things in the software, to work with the distribution. This is OK, but they should probably mark this in some way, such as a nonstandard version number (e.g. "1.5.2.debian.1") or a different name. Possibly such nonstandard version numbers should also be included in the software itself if it has the capability to display its own version number, and not limited to the package manager. Sometimes there is a separate list of patches applied than the version number; this might also be usable (instead of or in addition to the version number).