Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute.
New contributions require a person to forego the conveniences which the fossilized tools don't support well, and that friction _might_ contribute to fewer smart people wanting to contribute to your project. Consider as the OSS world's equivalent of a sales funnel. The more I need to deviate from the way I normally work, the less likely I am to want to make that contribution.
For a project where the overloading of maintainers is an issue, it might be worth considering the value of making it easier for other people to contribute. Sure, smart people who want to contribute _can_ adapt to the way your project wants them to work, but not all of them will want to jump through that extra hoop.
> Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute.
I think I'd rather not have my kernel code written by someone who is afraid to use an email client.
Email is not, FWIW, fossilized. It's far superior to GitHub or Slack, because it's decentralised and truly free.
Could you show your work? You're valuing "decentralied and truly free" as significantly more valuable than (far superior to) the sum total of GitHub Slack features. Could you list out the GitHub Slack features that you considered (and which ones you didn't consider) and your heuristic for their value and how they all combine to be much, much less valuable than decentralized/free?
- multiple clients on emacs (e.g. Gnus, mu4e, NotMuch)
- does not require a browser, ever
- does not require executing untrusted code on my computer, ever
- open protocols
- multiple servers on multiple platforms
- federated
Github, Slack et. al.:
- may have a decent text-only client (e.g. there's a Slack mode for emacs, and there are some GitHub clients out there, which may or may not be convenient)
- strongly encourage and sometimes mandate use of a browser with execution of untrusted code allowed
- protocols controlled by a single organisation, with no possibility to add functionality on the server side
- servers controlled by a single organisation
- no federation
- fundamentally proprietary
What I value: freedom; TUI clients; emacs clients; open protocols; being able to run my own service.
You listed only positives for Email and only negatives for Github etc. but you implicitly made the claim that decentralization and freedom are more valuable than all of slack and Github's features combined. Or are you saying that the value of everything except your "what I value" list is zero, so all of github/slack's objectively useful features are weighted to zero in the calculation?
> you implicitly made the claim that decentralization and freedom are more valuable than all of slack and Github's features combined.
I can't speak for others here, but personally I treat freedom as my first priority: it doesn't matter what features a platform offers if it doesn't offer freedom, because I will not use it if it doesn't offer freedom, therefore I'll never see any of those purported features.
Forget "afraid". Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community.
If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).
> Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community.
Again, I'd rather have my kernel code written by someone who has respect for others, and doesn't view spending a little time learning how to be productive in a group as 'jumping through hoops to learn the obscure workflow of an old community.'
> If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).
That's true, but the same respect-for-others is valuable in the other direction.
Over time, the number of people who are _willing_ to learn your conventions, versus those who _want_ t o use those conventions, may change. You may have several colleagues (and many more who have not yet contributed) who are willing to use email, but would prefer a web-based collaboration platform.
Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. Rejecting those out of hand as "not productive" seems a bit strange.
> That's true, but the same respect-for-others is valuable in the other direction.
Very true! And certainly not all change is bad, and not all new things are worse than their older analogues.
> Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail.
True enough, but I wonder how much of that is not because they are fundamentally better but because email has gotten popular. I can't easily review source code via email because I have to wade through meeting invites, corporate communications and recruiter spam.
Honestly, though, GitHub doesn't really give me a whole lot, other than centralised issue tracking and a data store. I never use its git UI; I just use Magit locally. I've actually been thinking about how a team could use commands to manipulate text files in a git repo to manage history for that repo — then one would never need to leave one's editor to manage issues. With a central file server open to users, merges and PRs could just be operations on the repo itself.
My idea's not fully fleshed out, but I think it'd be awesome, and more productive that using GitHub via a web browser.
> Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community.
Strongly disagree. As a general observation, people who don't have the patience to learn community norms generally don't have the patience to follow coding styles or write tests or properly document their code.
Maybe that's a feature? If something as simple and straightforward as a mailing list is a "nightmare" for someone, I certainly wouldn't want kernel patches from that person. If they don't have the patience/tenacity/knowledge/whatever to deal with email, then they sure as heck don't have those qualities in sufficient quantities (yet) to produce more signal than noise in an open source project.
In this sense, having a developer mailing list is like FizzBuzz for potential contributors- if they can't handle the easy stuff, they definitely won't be able to effectively contribute as software developers to a nontrivial project.
Another nice thing about email is that in practice, it's a slightly more formalized form of communication. Lots of people write terrible emails, but lots more people type terribly written messages into little boxes on web sites. The nature of the medium (in my experience at least) is such that people are much less likely to treat email like chat than they are to treat web forums like chat, and they're much more likely to make an effort to communicate effectively, which is absolutely critical for successful distributed development.
Finally, I think people forget that it's not necessarily a net good for the users of an open source project to have the most frictionless mechanism possible for interacting with or sending patches to the developers of those projects. People who are new to open source, especially if they're new to software development in general, sometimes have this ideal that more community is always better than less community, and more communication is always better than less communication, and more patches from the community are always better than fewer patches from the community, but I don't think this is true at all. It's very dependent on how the project is run and the goals of its developers. It can be a net good for the whole project to have some hoops that people have to jump through before they can start pestering the developers with patches, and email is about the most trivial hoop there is. Lots of projects intentionally erect many more barriers than that, and that's not necessarily a bad thing. The goal of most open source projects is to produce high-quality shared software, not to be a social experiment with the lowest possible bar for involvement.
For a project that needs to last more than 5-10 years, using really boring (fossilized?) communications archive tech is a feature, not a bug.