💾 Archived View for idiomdrottning.org › release-early captured on 2022-04-29 at 12:27:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
➡️ Next capture (2022-07-16)
-=-=-=-=-=-=-
FOSS doesn’t and shouldn’t wait until it’s finished to be released. It’s a “hey, here’s what’s cooking in my kitchen right now”.
Someone hacked something up for their own use. They can keep it in their own local/bin drawer for all time, or they can upload it as is without a warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
It’s better that they upload than not upload.
If the goal is accessible software, it’s still better that they upload than not upload. Because it’s a start.
If people are gonna get attacked for what they make and share then that’s fucked. I’m not onboard with that policy. Keep on releasing in the free world.
Now, do I flinch everytime I see someone push hobby-level phones like PinePhone (or the one I’m involved with, Mudita, which is even crappier in the accessibility department) as if they were polished and ready? Yes. It’s not ready and done until it’s accessible.
But I stand by releasing unready things.
When billion dollar companies can make something that, in some areas and aspects, outperform what indies, smaller companies, and hobbyists can make, that’s saying… that a corporation with full-time paid accessibility team can do things that a one-person show can’t.
The discourse on here is that if you release something that is bad at RTL or calligraphic text, or doesn’t interface well with screen-readers, then you’re a racist and an ableist.^W^W^W^W^W^W^W (I can’t believe I used that stinky old rhetorical device, I’m sorry.)</i>
Sure, if the software had been locked down to only be that. Since there’s an open license, other people can build on it.
The release-early philosophy is like… say the goal is to build shelter for homeless and someone contributes a plot and foundation, and give that away without walls or roof yet. If that were here on Fedi they’d’ve gotten their head bitten off for not providing a wheelchair ramp yet.
Now, it definitively is fair to criticize charge-money-early, or market-early, or set-up-a-customer-relationship early. “Release early and share what you’re working on” is a great FOSS philosophy that in just a few decades has changed our world to be more inclusive of hobbyist level devs, people who, alone and in their free time, make and share amazing stuff not just in software but in music and literature. Unfortunately, that has opened the door to a sort of quasi-hobby, quasi-commercial world that wants the best of both worlds: all of the money but none of the responsibility. Kickstarters that release garbage after months of waiting, for example. I’m not defending that at all.
What I am saying is that I’m definitively not on board with dissing the release-early philosophy and the warranty disclaimer that enables that philosophy.
We can’t get to “done” without taking those first steps. This goes double for features like accessibilty and localization, which are specialized subfields of software design. Those features are especially helped by a larger team and the only way to build a larger team is release-early.
Saying “hey, garage dev, fuck you if you haven’t mastered feature X, Y or Z out of the gate with your first release” is the same as expecting every single dev to master all fields. Talk about gatekeeping! Except it’s probably very few devs who are both blind and masters of Arabic typesetting, right? (Not saying zero devs can do that, just trying to say that different devs can usually have different strengths.) When humans cooperate, pool their strengths, and work together, we can make things that are more then the sum of the parts. Release-early is the stepping stone towards cooperation. It’s opening the lab doors a bit and seeing if anyone in the neighborhood can help make it better. I’ll never sign off on an attack against that.
Yes, good can be the enemy of perfect but good can also be the stepping stone towards perfect. I believe that is the case with release-early software.
“Good” is the enemy of “perfect”
If people are gonna get scorned, attacked, held responsible and accountable for releasing stuff then I’m not onboard with that. This stuff exists because someone thought “enh, might as well upload it as not upload it”. People shouldn’t get punished for uploading, nor be roped in to be the ones responsible for every lacuna.
We agree that the Earth would be a better planet if some app, say Gnome 4, had non-crickets accessibility.
We agree that it would be good if someone added that.
I’ll even grant that since some people (for example those who made it) know the code base better than some other people (for example those who have not made it), it is often ideal if those who do know the codebase get involved witn the accessibility and internalization efforts
What I don’t sign off on is that those people should be mandated to be the ones to add those features, to be responsible for them, to be accountable for them. Releasing FOSS should not come with strings beyond “don’t be actively malicious”–don’t release viruses or revenge porn, for example.
I’m gonna call this the death clause. It has to always be legal to die after releasing software. I should not be mandated to keep working on it.
People wrote more and I wrote more.
As I noted in my original reply, I would be in full agreement if the criticism was against over-hyping, over-marketing, over-charging, over-promising. That is the true enemy. That is the part of the talk I am specifically against.
I don’t mind criticizing Gnome, PinePhone, or Mudita for being bad at accessibility. Heck, I criticized a FOSS project myself the other day (pulseaudio).
And OMG I can’t belive I did the “if you such-and-such then you get labeled a such-and-such” Karen move. That was awful. Instant regret.
What I do wanna adamantly say though is that I stand by the “death clause”. Releasing something comes with obligation that it’s not actively malware, but not with any obligation ever that the person is gonna keep working on it or any merchantability or fitness etc.
Releasing not-early should be just as allowed as releasing early. That’s fine.
Labeled buttons have two parts. The labels and the buttons. You can make them three ways:
We all agree that labeled buttons are what we want. I appreciate unlabeled buttons as a stepping stone to labeled buttons, not as an enemy of labeled buttons.
It’s like a potluck dinner. If someone brings salad and gets beaten up for not bringing any dressing then that’s not a cool party.
I believe release now and fix later is good for inclusive design. Bookwyrm is a good example since it actually did release very early. It had contributors as early as a few weeks after the initial repository, while it was still only in a skeletal state, and many of the accessibility and internationalization features were added by contributors that were able to do so because the code had been released early.
Does Linux culture have an accessibility and ableism problem? Yes, a bad one, unfortunately. But that is because of other factors, not because of release-early.
Selling early, hyping early, promising early… those are bad things. Releasing early is part of the antidote to that. That’s what happened with Bookwyrm; people could and did contribute fixes.
I then wrote:
At what stage does a “standard of quality” apply?
My point throughout the thread has been to rail against overselling, but to conversely encourage early uploads. Just basically make the folder and git init; git commit -m "Initial release"; git push is fine by me.
And Eloquence replied:
As an example, I think places like the “storefronts” and package directories are a great place to include more structured data about a11y, i18n, usability assessments, security audits, and other aspects of software quality - to make it easy for folks to filter.
And distributors often choose the default app for a certain purpose, which is an opportunity to highlight the best available software for a given task, and should take those criteria into account.
Sure, I’m definitively on board with that!