Ludovic Courtès
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.
🧵
Ludovic Courtès
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.
Ludovic Courtès
In #Guix we’re discussing a deprecation policy to serve both as a guideline for contributors and as a “contract” with users:
https://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!
Ludovic Courtès
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!)
Francesco P Lovergine :debian:
@civodul
There is a well-known deprecation policy for Python.
https://peps.python.org/pep-0387/
I like the deprecation documentation in Perl, which is very precise. Specifically, some features are introduced as experimental and possibly deprecated if they hurt more than they are perceived as an advantage.
https://perldoc.perl.org/perldeprecation
In the case of very large projects, like a distribution, I don't think a deprecation policy is really practical: there are too many variables due to subprojects....
Ludovic Courtès
Anyone knows of similar deprecation policies in other malleable software projects?
Daniel S. Katz
@civodul I heard an interesting talk from Matlab folks a couple of years ago where they described their depreciation process. If I remember right, they had releases every six months, and wouldn't deprecate anything (or make any changes that could break user code) with less than 4 releases (2 years) of notice.
Mans R
@civodul Matlab comes to mind. I know it's not open source, but that's beside the point here.
ghisvail
@civodul given the large surface area of Guix, I think we could take a page or two from either large distributions like Debian (apt and dfsg policies) or programming languages (Python, OCaml, Scala, ...)
Janneke
@baleine @civodul
I wrote a patch for the Gnome window manager once, Mutter I believe it was, to make it programmable with Guile. Mutter had Gnome integration so that made a lot of sense to me. It was outright rejected because "we don't want our users to program their desktop" or something. Went back to sawfish/sawmill and a happy #exwm user now. Other than the odd config debacle :)
Noé Lopez
@civodul Agreed about EXWM, this is why I use GNOME: the reliability and touch controls make for a great experience even if its at the cost of customization.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.