5 ms·

Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the

by gknoy 10y ago

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.

zeveb 10y ago
> 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.
- vehementi 10y ago
  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?
  - zeveb 10y ago
    Email: - multiple clients on multiple platforms - 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.
    - vehementi 10y ago
      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?
      - chriswarbo 10y ago
        > 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.
- azernik 10y ago
  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).
  - zeveb 10y ago
    > 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 a-okay by me.
    - azernik 10y ago
      And I'd prefer to have my kernel code written by a community that cares about its long-term health and efficiency rather than respect.
    - gknoy 10y ago
      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.

by gknoy 10y ago

zeveb 10y ago

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

vehementi 10y ago
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?
- zeveb 10y ago
  Email: - multiple clients on multiple platforms - 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.
  - vehementi 10y ago
    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?
    - chriswarbo 10y ago
      > 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.
azernik 10y ago
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).
- zeveb 10y ago
  > 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 a-okay by me.
  - azernik 10y ago
    And I'd prefer to have my kernel code written by a community that cares about its long-term health and efficiency rather than respect.
  - gknoy 10y ago
    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.