Jan Wildeboer 😷:krulorange:
In the olden days, a FOSS (Free/Open Source Software) project typically had:
- A source code repository
- A web page with the documentation and links to downloads
- At least one mailing list called announce, typically also one for users and one for contributors, all with public archives
- An IRC channel to chat with other users and maybe also the developers
Maybe it’s time to try that simple approach again? Everything open, everything accessible? 1/4
Jan Wildeboer 😷:krulorange:
In those olden days, we also had some helpful rules. One was that only things that can be referenced in code or mail archives actually exist. So when there was a long discussion on IRC, someone wrote down the outcome (or coded the patch) and made it accessible to all. This was an important rule to avoid excluding those that didn’t have the time/willingness/connectivity to spend hours on IRC. 2/4
Jan Wildeboer 😷:krulorange:
When I now see slack, discord, github etc everywhere as a requirement for participation, I know that we are exchanging a bit of comfort for the IMHO very high price of excluding a lot of potential contributors and giving a lot of data to proprietary companies without a real need for that. 3/4
/home/leandroramos
@jwildeboer I will never understand why some #freesoftware projects centralize conversations in things like Discord and Slack.
Daniël Franke 🏳️🌈
@jwildeboer When I got more involved with the Kubernetes community, it was also my first encounter with Slack, and having the main communication channel of an open source project be proprietary always rubbed me the wrong way.
feld
Jan Wildeboer 😷:krulorange:
@feld I don't even think of using IRC that much. I am describing what we did in the past and how all of that had one thing in common: being open and accessible. Compare that to having to have accounts on two or three external (proprietary) services *per project* you are interested in. THAT's my point.
feld
Fish of Rage
feld
Fish of Rage
Fish of Rage
feld
Fish of Rage
Jan Wildeboer 😷:krulorange:
@feld The very first question should always be: how much value do these services bring to your project and at what price? Devils advocate question: do we really need these tools or are they maybe a time and resource black hole? I for ne wouldn't even think of adding discord, matrix to my projects. Code, issues, releases via forgejo/codeberg/github , a homepage and maybe a mailing list would be enough for me. So I guess I am the wrong person to ask about alternatives ...
feld
Fish of Rage
feld
:blank:
feld
Fish of Rage
Zergling_man
vv221
Haelwenn /элвэн/ :triskell:
Haelwenn /элвэн/ :triskell:
vv221
vv221
Jan Wildeboer 😷:krulorange:
Seeing how quite some commenters (want to?) take the wrong conclusions from my thread: I am all for the GitHub/gitlab/forgejo/codeberg based approach of managing issues, PRs, releases in "modern" ways. It made drive-by contributions so much easier! I am however not sure if discord et al are better for asynchronous communication and feel that mailing lists with public archives were a superior approach that we gave up on prematurely. HTH! 6/6
Jan Wildeboer 😷:krulorange:
I am throwing this out here not to come over as a grumpy old man, yelling at the clouds. But because I guess many enthusiastic, young people simply never experienced the olden ways. Maybe they want to explore them a bit and see for themselves if there could be something viable in it for them. Especially wrt async communication. Is all! 5/6
Jan Wildeboer 😷:krulorange:
Maybe this short thread makes you think a little bit about that. That would mean a lot to me! Run your projects in every way you want, I am not telling you to make changes. I merely hope that you start to think a bit about what's best to grow your community in an inclusive and open way, is all :) 4/6
anna
anna
anna
Luna :neofox_snug:
@jwildeboer mailing lists and IRC channels are like the opposite of accessible
to elaborate:
IRC is unusable on mobile internet connections, or on multiple devices at once, doesn't keep any history and has none of the features you would expect from a chat protocol in 2024 (yes bouncers exist but they are extremely convoluted to set up and often assume you have some arcane knowledge on how IRC works that doesn't seem to be actually documented anywhere)
Mailing lists clutter your inbox with tons of discussion you don't care about and are very difficult to read especially when a thread splits into multiple branches.
The best way I've seen of solving it is to display threads like Reddit or Misskey does, but I have never seen anyone implement a way to read mailing lists like that. Most forum software just ignores the problem by not supporting any way of "forking" a discussion, which results in terrible, impossible to follow threads where every other post quotes some previous post related to a different topic (see XDA-developers).
Also my email provider would ask me to pay up for the volume of received email if I joined a few mailing lists each receiving dozens of messages a day.
If a project requires me to join a mailing list to contribute I will simply not contribute to the project. Git forges exist for a reason, they provide really good UX for merge requests and issue tracking.
vv221
Grant
@jwildeboer Some time ago I created a feature for a popular code editor. I thought it would be helpful to others so I posted the code on the 'issues' thread. But actually, I should make a pull request and a fork and feature..merge.. I don't know. It's 6 lines of code, take it or leave it. I know "Pull request" is probably a matter of course if you're already a frequent open source contributor, but it'd be nice to dip my toes in the water without pushing me into the deep end.
feld
Anthk
@feld @jwildeboer IRC or XMPP won't change the API. Discord can be useless tomorrow. And you need a propietary client to join.
feld
:blank:
:blank:
feld
:blank:
feld
þernia
feld
feld
feld
:blank:
Fish of Rage
:blank:
:blank:
:blank:
Fish of Rage
feld
Fish of Rage
Fish of Rage
:blank:
ロミンちゃん
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.