Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not ship work in progress: An open letter

dont-ship.it

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Do not ship work in progress: An open letter

#51

Post by remram »

I wonder if this could be solved with license terms.

Popular, OSI-approved licenses include clauses like "Neither the name of the 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...

Re: Do not ship work in progress: An open letter

#52

Post by wongarsu »

speeder wrote: post #49

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.

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)

Re: Do not ship work in progress: An open letter

#53

Post by droobles »

voydik wrote: post #46

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.

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.”

Re: Do not ship work in progress: An open letter

#54

Post by andix »

jsty wrote: post #9
andix wrote: post #5

Earlier quoted context omitted.

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.

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 a…

I’m more concerned about changing the license of contributions during merge to master or a release. That something goes wrong there and the whole code base ends up „poisoned“ with non free code.

Software licenses need to work in a lot of different legislations, and it’s really hard to make a license that means the same thing in all countries.

Re: Do not ship work in progress: An open letter

#55

Post by pledess »

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."

Re: Do not ship work in progress: An open letter

#56

Post by j16sdiz »

MartijnBraam wrote: post #29
jstanley wrote: post #25

> 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?

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.

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

Re: Do not ship work in progress: An open letter

#57

Post by detaro »

hulitu wrote: post #42
Spivak wrote: post #18

Earlier quoted context omitted.

Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.

> Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. Then don't do 15 different versions of your software. I ask again: Why do i need GTK1, 2, 3 and 4 on my system ? Why KDE 5 is not compatible with KDE4 ?

Versions != major releases

Re: Do not ship work in progress: An open letter

#59

Post by crest »

Spivak wrote: post #18
kop316 wrote: post #16

Earlier quoted context omitted.

> 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.

Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.

No. They asked distros to ship their latest release as default version instead of recreating Frankenstein's monster holding onto end of life releases for ages backporting random patches without understanding the code they're messing with and blaming the upstream projects when their patches inevitably introduce more regressions and less features than any well maintained upstream project.

Of course this is a very one sided view. I've been on the receiving end of reckless upstream projects far too often not to understand why distributions which are expected to maintain compatibility with releases for years dislike a fast moving upstream for anything too important.

Manjaro Linux is accused of something different far less justifiable: forking upstream projects in all but name by shipping heavily patched packages without supporting them and even worse putting the support burden and blame on the upstream projects when things break (and oh boy do they break).

Re: Do not ship work in progress: An open letter

#60

Post by WesolyKubeczek »

simiones wrote: post #23
WesolyKubeczek wrote: post #15

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 bu…

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 ille…

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.

Post reply on HN