Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante https://www.tc54.org/contributing-yaml/ although I think all of these file types end up going stale pretty quickly
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard. -
@mhoye super cool!
-
@tante But that's what most open source licenses already say: PROVIDED AS IS
For me that's as clear as I can be. Of course that also means I won't try to convince people to use my code. Or if I ever do that and present at a conference, my talk will mention this part of the license.
@odoruhako that's the legalese framing (which is mostly a "we don't wanna be sued" solution). But projects _do_ act differently and bigger projects do - voluntatrily - to way more: Defined release cadences, support windows, etc. And that is to a certain degree the expectation that people have been trained on - even though it does not scale especially not to single developer projects.
-
"I will not maintain this code at all. Use fully at your own risk" is valid.
I think it's just important to make that clear.
@tante
In this blessed month of mercy and giving,In Gaza, children are not asking for much… just a small moment of joy and a real smile.
Our children deserve the best.
With a simple donation, you can make a true difference in a child’s heart.Never underestimate a small gift… for them, it means hope. 🤍
Support Gaza's children: Restore joy and childhood today
In Gaza, children grow up amid fear, loss, and constant stress. Many have forgotten what it feels like to simply be a child, and the impact is lasting. We are a small volunteer team focused on psychological relief and emotional support through safe spaces, games, art, and group play that help children release fear and rediscover joy 🎈.
Chuffed (chuffed.org)
-
@tante But that's what most open source licenses already say: PROVIDED AS IS
For me that's as clear as I can be. Of course that also means I won't try to convince people to use my code. Or if I ever do that and present at a conference, my talk will mention this part of the license.
@odoruhako @tante I’m continually surprised at how many people insist that there somehow entitled to free support from a BSD licenced project.
We care about our code, its usability, and our users, and we welcome active contributors.
If you’re a company then the onus is on you to find ways to contribute to the commons, & not just demand free help.
If you’re slurping it up with AI (and burning our resources while doing it) & turning our commits into your product, then that applies even more so.
-
"I will not maintain this code at all. Use fully at your own risk" is valid.
I think it's just important to make that clear.
@tante I think this is the baseline unless anything else is explicitly stated.
(The reverse timeline algorithm led me to this only after the previous post.)
-
@mhoye super cool!
In the Nebula project, we have a project status section at the end of https://nebula-plugins.github.io/documentation/plugin_overview.html that addresses some of this stuff.
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard. -
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante or how much work to maintain for the sysadmin to update/upgrade between versions... That's usually my first question.
-
-
@mhoye super cool!
@tante @mhoye maybe something like this could be built into #radicle https://radicle.xyz
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante
"There is no project. No development team. This scratched my itch. You are welcome to the code." -
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante
A while back I found an essay titled "Healthy expectations in open source" by @donmccurdy that proposes just such a standard:
https://www.donmccurdy.com/2023/07/03/expectations-in-open-source/I found the classifications well thought out and have started to use it for my own small projects.
This was the accompanying Fediverse post: https://fosstodon.org/@donmccurdy/110662029314944366
-
P pixelate@tweesecake.social shared this topic
