Conversation
Edited 2 months ago

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
- (maybe) 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

2
1
0

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

1
0
0

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

1
0
0

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/4

1
0
0

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 it could be something viable for them. Is all!

2
0
0

@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.

1
0
0

@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

0
0
0

@jwildeboer

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 :)
So I think it was less of an issue back then, because not EVERYTHING was on GitHub. Now it gets more difficult to get people to do a bit more effort to contribute, is my feeling.

0
0
0

@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.

2
0
0

@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.

1
0
0

@ef4 @jwildeboer The problem is not Git, it's Github. You have several libre alternatives, even self-hosting.

1
0
0

@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.

1
0
0

@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.

0
0
0
@ef4 looking forward to your contributions to my Darcs hosted project
0
0
0