Do not ship work in progress: An open letter

by sellweek • 4 years ago

161 75 4 years ago

blueflow• 4 years ago

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

andix2• 4 years 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• 4 years 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.

mikepurvis• 4 years ago

Preventing distros from patching software at all would be a non-starter; there are lots of legitimate reasons to want/need to patch things.

Indeed, most patches I see in off-beat systems like nixpkgs, homebrew, etc, are not plucked from preexisting pull requests, but rather are fixes developed by the person who did the packaging and submitted upstream, then included as a patch until the first tagged release that has them merged.

selfhoster11• 4 years ago

Why would it fix the problem? That's besides the fact that this would complicate the legal situation of the project, including that of contributions.

mittermayr• 4 years 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_bash2• 4 years ago

Same, I thought it was going to be an argument about MVPs

antonvs2• 4 years ago

Many startups wouldn't ever be able to get started under a restriction like that.

eastbound• 4 years ago

“If you’re not ashamed of your first version, you shipped too late.” Reid Hoffman

remram3• 4 years 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"

kop3162• 4 years ago

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ Comments: 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/ was started.

rob742• 4 years 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?

ddevault2• 4 years ago

Distributions like Manjaro should change their behavior and quit shipping unfinished patches.

kop3162• 4 years ago

start calling themselves "nightly" distros

It's not a "nightly" distro, it's a "let's take patches that are unfinished, release them into the wild onto unsuspecting users, and let the upstream developers deal with it" distro.

COGlory• 4 years ago

openSUSE Tumbleweed

srmrqaz• 4 years ago

I always thought that the whole point of Manjaro was to be the "more stable" Arch linux, since it holds the rolling updates and releases them at once every month. Is that not right anymore?

sillystuff• 4 years ago

I think this is asking that we avoid additional episodes like the Redhat gcc "2.96" issue where redhat took cvs head, and slapped a version number on it that would have been the next release and shipped it with their "stable" distribution. GCC devs got tons of complaints about their shipping a broken compiler that couldn't compile the kernel and tracked it down to redhat shipping pre-release WIP software as if it were the new release version. GCC completely skipped the 2.96 version number, so "2.96" ended up being a redhat exclusive-- the fake 2.96 would have been a recurring source of pain due to confused redhat users making bug reports to the gcc project.

https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...

scrame• 4 years ago

Is there any dev methodology that doesn't get bogged down by process?

RunningDroid• 4 years ago

Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

Void Linux

quickthrower2• 4 years ago

That should be common sense. Shrug.

bin_bash2• 4 years ago

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

O__________O2• 4 years ago

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

Rackedup• 4 years 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.

pessimizer2• 4 years 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__________O2• 4 years 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.

WesolyKubeczek3• 4 years 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• 4 years 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• 4 years 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?

WesolyKubeczek3• 4 years ago

If a user comes to me bothering me about some package some distro made of my software, I show the part that says NO WARRANTY and AS IS, and get on with my life.

Also, why should it “bother” anyone at all. You duke it out with whoever brought it to you.

It’s only a problem if you feel a need to please everyone knocking on your doors, which inevitably turns into burnout and you actually behaving harshly towards everyone in the end.

jstanley• 4 years 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?

MartijnBraam3• 4 years 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• 4 years ago

The page is missing all these contexts. It don’t make much sense on its own

natch3• 4 years 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• 4 years 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.

natch3• 4 years ago

I wouldn’t say it addresses it so much as it acknowledges it as an issue without offering a workable solution.

jwildeboer• 4 years 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• 4 years 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 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• 4 years 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• 4 years 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• 4 years 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• 4 years 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• 4 years 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)

remram3• 4 years 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• 4 years ago

I think you could just assert that unmerged PR's have the following license:

remram3• 4 years 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• 4 years 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-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• 4 years 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• 4 years 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• 4 years ago

What does this anecdote have anything to do with the article?

donmaq• 4 years 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• 4 years 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).

Do not ship work in progress: An open letter

Related Stories