 (Thread) In the olden days, a FOSS (Free/Open Source Software) project typically had: - A source code repository Maybe it’s time to try that simple approach again? Everything open, everything accessible? 1/7 119 comments
When I now see slack, discord, github etc everywhere as a *requirement* for participation, I think 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/7 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/7 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/7 @jwildeboer I've been contributing/following a few big projects that only use mailing list based contributions (Yocto, U-Boot bootloader, Linux kernel, libcamera, Buildroot). The last few years we've seen a lot of people voicing their discontent at that workflow and requesting we do everything with GitHub/GitLab "or else you will never get a contribution from me". So I am not sure those young people are that interested in that old workflow. @0leil And I support them with that. The very old workflow of creating patch/diff and sending that around is dark magic :) With issue and PR management a la Github/Gitlab/Gitea/Codeberg a lot has become a lot better. @0leil Please do! I will also start a blogpost on how Discord etc mess up communication in a project (IMHO) by mixing synchronous and asynchronous communication together in a way that isn't helpful but, again IMHO, damaging to the flow.  @jwildeboer @0leil It sucks, period. A mail list/usenet gives you all anytime. @0leil @jwildeboer Per-commit review is a point that I hadn't considered. With GitHub's PR UI only making the end result of all commits together apparent, I could see someone introducing a security vulnerability in a commit, fixing it in another, and then tricking a packager into publishing the version with the vuln... @jwildeboer ah and before I forget, there's this tool called b4 now that aims at making patch sending for mailing lists a bit easier. I personally have switched to that for the last 1+ year, I am NOT looking back. git-send-email? I now say no no :) I'm still in my early thirties but I think I was probably one of the last generations where GitHub was not in basic monopoly for anything-git. At university it was still a decision which to use and some were still using Dropbox :) @0leil I come from the time when version control was an esoteric topic at first, tarballs and patches ruled. Then I started using CVS and along came Sourceforge, which many projects used. That was what git and GitHub are now, more or less. So yes, better tools, but still the same (centralised) setup. Forgejo/Codeberg are working on integrating ActivityPub by using #ForgeFed [1] and I have high hopes that that will introduce truly better ways and real progress. @jwildeboer I have contributed with Gerrit, GitLab/GitHub and mailing lists. Nothing works 100%. Every workflow is broken in some way and it's just always in the way. It's just that when one person is used to one workflow, they learned to live with those and it hurts to see how you work now not work in another workflow. I for myself have given up on something that's nice to use and I'm just internally complaining at everything :) ol' grumpy man yelling at the clouds like you said 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/7  @jwildeboer IRC wins for discussions by not requiring anything. You want to chat? Click the JavaScript client link and chat. You can install a optional client if you plan to chat often. You don't need to register or provide any personal details. Matrix/Discord etc all fail with onboarding and high hardware requirements for a client. I can sign into IRC using any computer with networking, even obsolete hardware. NetBSD on a Apple llc, IRC on a palm pilot. Take your pick. @jwildeboer Discord isn't good for most things outside of "smilies". Just a hair better than Slack which doesn't say uch.  @egoalter @jwildeboer It does have better moderation tools, replies, text formatting, internal links, onboarding tools, etc. @csepp @egoalter @jwildeboer It is a lot better than Matrix. I manage the chat infrastructure of an OSS project that spans Discord, Telegram, and Matrix (it's geared towards the kinds of people that use those services as well as neckbeards, ok fine it’s @blendOS), and while Matrix has Draupnir which works okay, it's hard for us to use anything else because Discord has the best admin tools and bots available.  @david_chisnall @jwildeboer Signal is a clever use for this, but I think for many projects it would be best if there was accessible chat history and search.
You've got me thinking though... @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. @jwildeboer I would also like to add a story here... I was participating in a project some XX years ago, which was highly active, largely with younger people, very much coordinated through IRC, though we also did a bit of mail. I was mentored, on a specific project and I noticed my mentor preferred mail, which was fine by me, but a bit unusual for that project. I found out the reason when I met him, because everything he typed, he typed with his mouth. So I learned: Requiring chat is abelist. @nobletrout @jwildeboer Hard agree. For me this is about project governance, and infrastructure governance along with sustainable fund raising models (includes corporate sponsors). We must raise funding to support FOSS solution providers that respect privacy and user freedoms. Unpopular opinion: It does a disservice to our communities if we all stand up forgejo instances without considering that if we all put that money towards something like CodeBerg, that we might get a solution we all need. @codonell (FTR: I am a paying member of Codeberg, moved most of my projects there and am also running my own forgejo instance :) @nobletrout @jwildeboer @nobletrout I figured you were, and I wrote "without considering" purposely. It is absolutely OK to do this for yourself, I don't object to that, but as @nobletrout says, and I agree with, we need a mindset change where we consider our options and their consequences. Consider if the top 3 downstream distribution put all of their sources on CodeBerg, and put all that funding in the same place? Imagine being able to do PRs against the same debian, gentoo, and fedora sources? @codonell I am not a big fan of centralisation. Forgejo is working hard to integrate ActivityPub so that ultimately you can file issues, pull requests etc to any instance with your preferred AP account. It's going to take a while to get there, but that's the future I am hoping for. Decentralised, distributed, open. @nobletrout  @nobletrout @jwildeboer @jwildeboer I will never understand why some #freesoftware projects centralize conversations in things like Discord and Slack. @leandroramos @jwildeboer i think it is more managable , of course, i agree with you, these things should be free for use, comunication and so on @jwildeboer How is requesting a GitHub account "very high price"? Or put another way: is your solution to go back to *exclusively* IRC and mailing lists, or to have *both* systems to give people choice (and place the burden on maintainers)? @astrojuanlu When GitHub started using my code to feed it to their Copilot LLM with now way for me to opt-out, I decided the price was too high. But that's just me. I still have a GitHub account, but moved my code to Codeberg and my own Forgejo instance. @jwildeboer Slack & Discord are walled gardens. Unusable for proper OpenSource projects. #bash #sh #zsh #ksh #csh #100DaysOfCode #Linux #freeBSD #netBSD #openBSD #POSIX #Programming  @jwildeboer we have the history of Twitter as a hot example of what exactly could go wrong, and yet  @jwildeboer not a fan of how using discord for documentation essentially means you have to make friends with the maintainers to use their code. i don't have a problem with making friends but that shouldn't be a prerequisite for interacting with the project. feels very similar to the new york times making you call a phone line to unsubscribe  @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.  @jwildeboer IRC has also developed a whole lot of moderation tooling which simply doesn't exist yet on alternative platforms and moderation is a key component of accessibility @jwildeboer esp since IRC can now be self-hosted on the project domain with a javascript client on the project site instead of requiring a separate client seems like there are lots of reasons to use it @jwildeboer I really miss that and can’t take projects seriously that have their community in Discord. I was really happy to see discuss was able to bridge between forum and ML users as you could configure it with both options available.  @jwildeboer the abandonment of mailing list is what bums me the most. Several big project replaced it with "discourse" whose usability is dubious. I ended up losing contact when they closed the mailing lists. But then mailing list got killed by GMail, 20 years of killing email and counting   @jwildeboer It worked, it was transparent, simple, and kept everyone within "the know" as needed/wanted. Lately, handful of idiots throw some slapped together, "ai reviewed "code" into some GitHub repo, and send everyone to discord. Blagh. @tebrown @jwildeboer Unfortunately if you wanna appeal to anyone other than neckbeards you gotta be where the people are. Explaining to people how to use IRC (yes they can click a button but they'll still find it lacking a lot of features) or a mailing list is a serious waste of time There was also source code and patches published to Usenet. I don't recall how much took place there but it was generally open and accessible. (Some newsgroups were moderated.) @jwildeboer I did OSS in that era and I do it in the GitHub era and sorry but no way I’d want to go back. The big gap is de-facto standardization of workflow. I can do a drive-by contribution to a project in minutes, where in the olden days I simply wouldn’t have bothered because I had to spend an hour learning their bespoke workflow. @jwildeboer decentralization would be great, but only with a standardization that definitely did not exist in the past. Also: LOL at the conceit that the work of moderating mailing lists and hosting infrastructure was the “simple” way. @ef4 @jwildeboer The problem is not Git, it's Github. You have several libre alternatives, even self-hosting. @anthk @jwildeboer I understand the distinction. There are a lot of ways to use git, and you always need some additional tooling around it because git doesn’t manage queues of proposed changes, discussion of those changes, code reviews, etc. when that tooling doesn’t follow one obvious de-facto standard you’re still turning away contributions due to friction. @anthk @jwildeboer a self-hosted GitHub clone is fine, but it’s still extra friction (decentralized identity management and notification management with *good UX* remains an unsolved problem) and extra work for small OSS teams who are always short on resources. @jwildeboer +1 from another slightly grumpy old man. This seems like another aspect of the "slow evaporation of the foss surplus". Tying the workflow to proprietary source control / social media platforms cannot be the way forward.    @jwildeboer im only chiming in to promote #codeberg free open source, has most of the gitlab features MINUS THE SHITTY AI, and right here on mastodon @Codeberg @gi124 @jwildeboer @Codeberg However, github and gitlab strangle SEO rankings for projects. Search up the code for Crystal Linux's installer (run from gitlab self-hosted), I dare you. You have to have at least some kind of github/gitlab.com presence (even just a mirror) to be discovered. Not saying you should avoid Codeberg, great service. Just saying github is impossible to avoid if you want any users/younger contributors whatsoever.   @jwildeboer Cheers!  @jwildeboer No arguments from me. Discord, in particular leads to a very disjointed experience outside of developer chat when there's no documented / easy to find follow-up of outcomes. @jwildeboer I also want things to have insightful documentation as part of the release process again, not relying on things to get filled in as it goes because that creates a LOT of confusion and issues that could have been prevented by through and open discussions.  @jwildeboer@social.wildeboer.net Both mailing lists and IRC suck. There's a reason they were replaced. @jwildeboer @jwildeboer >At least one mailing list called announce, typically also one for users and one for contributors
fwiw I've never seen that work as designed. A lot of user questions went straight to contributors list - this is where all the cool kids hang out duh @jwildeboer Because I think we should _have_ some issue system somehow attached to a source code repository without relying on a central third party server (like github/gitlab/…), and we don't have one.  @jwildeboer@social.wildeboer.net Good idea! I am going to release the source files in a .zip file over a discord channel. @jwildeboer While I agree with the spirit of this post, from my recollection it wasn't all roses: - The source code repository was CVS, or SVN if you were lucky. Otherwise it was just versioned tarballs.  @jwildeboer  @jwildeboer one of my current bigger projects is having mailinglist and slack channel. I got in 8y one email from someone who was not me. Slack is low traffic but regularly used to ask questions and chat about a change/update or possible bug or missing feature. I enjoy it more than irc, because I can help other TZs with less effort.  @jwildeboer We even joked about projects that had “a website and a mailing list” and nothing else, since there were so many projects without any actual code. This means that a mailing list was obviously considered more mandatory than code by some. If you didn’t have a mailing list, you weren’t a project. |
Gregory's Server
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/7