society.oftrolls.com is part of the decentralized social network powered by Mastodon.
A nice little Mastodon instance. Mild trolling encouraged (keep it local), but not required. Malicious behaviour is not tolerated. Follow Wheaton's law and you'll be fine.

Administered by:

Server stats:

17
active users

Learn more

I’m a big fan of malleable and extensible software packages à la Emacs; I think they’re the way to provide practical freedom to users, when licenses provide freedom “de jure” only.

That one can gradually discover the code and fiddle with it blurs the user/developer distinction and reduces the dependency of one group on another.

#FreeSoftware

🧵

As a user, there are times when I’m in the mood for fiddling with the code I use, and others when I just want to get other things done.

I recently had my config “broken” by changes in a new version EXWM, the Emacs window manager.

It’s a situation where malleability gets in the way and could encourage some to turn to rigid solutions where they can hope to be an undisturbed “end user”, at the cost of decreased autonomy.

How can we conciliate malleability and some form of stability for user config and extensions?

I think #Emacs itself is the gold standard here: long deprecation periods and clear documentation. (Third-party Emacs packages are often not doing as good a job these days!)

In #Guix we’re discussing a deprecation policy to serve both as a guideline for contributors and as a “contract” with users:
issues.guix.gnu.org/72840

The latter is important: users should know that they can trust Guix to not change overnight without prior warning, that scripts, manifests, OS configs, etc. won’t break unexpectedly.

If you’re a Guix person, now’s the time to make your voice heard!

issues.guix.gnu.org[PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

Anyone knows of similar deprecation policies in other malleable software projects?

Mans R

@civodul Matlab comes to mind. I know it's not open source, but that's beside the point here.