4 ms·

Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spe

by mlthoughts2018 8y ago

Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. Most of the dysfunction I see in open source projects that take an ambivalent attitude towards the bug fixes and urgent feature needs of long-term users seems based in pure ego. Core devs want to keep being the leading edge designers and implementers of the project and are extremely stingy about letting new or intermediate contributors to the project bring fresh perspective and excitement into big new feature implementation or refactoring. You can make a lot of disingenuous arguments that this is to protect the style and design approach of the original core, but it’s not. It’s just ego. Look, people are obviously free to say if they are dedicating their free time to some open source project, then they only want to work on the aspects of it they like or the aspects that might seem glamorous in a blog post or conference presentation or whatever. Being “allowed” to take that attitude is pretty much inconsequential though. If you do that, your project is entering one of two modes: death mode where new developers realize you will only permit them to work on gruntwork and you lose any capacity to actually fix things because nobody joins your project, or North Korea mode like the linux kernel where some crazed monarch or oligarchs use intimidation and public shaming as primary code review techniques. If you are a really smart core dev of open source, stop working on the big new features. I know it hurts your ego to let your baby into the hands of newbies. Instead, do more code review, tutorials, answers on SO, and go way out of your way to make new contributors feel like you are impressed with their skill, that you want to pair with them through meaningful PRs right away, no “good first task” grunt work ego crap.

thrower123 8y ago
> Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. At this point you need management and support staff. Trying to pound square peg developers into those round holes is rather hopeless, especially when it is free work not paid.
- mlthoughts2018 8y ago
  Sure, I agree it’s still logistically challenging. I’m just claiming the hard part is the ideological hurdle of getting the original core devs of the project to willingly facilitate frequent “changing of the guard” where the burden of critical new features and design is wholeheartedly given to new and intermediate developers of the project, to graciously let other people take the reins and have the core devs with an attitude of service to their community of users, fixing bugs, adding small feature enhancements, and particularly creating excellent documentation and tutorials. That’s the first step. Templates, disqus boards, SO, etc., aren’t going to save you if the core devs view the open source project as a walled garden where they pick and choose what to work on based on a need to “be the one” who is responsible for milestones of implementation.
  - thrower123 8y ago
    What's the incentive to those developers to take on this pain-in-the-ass corporate kind of work, rather than just doing the work that they enjoy that made the project noticeable in the first place? Nothing is owed to anybody, if it's being made into unpleasant management work, you can just pick up your ball and go home and do something else. I'm not really sure I want new developers doing core work on a project, and would be somewhat skeptical of projects that did adopt such practices without heavy oversight.
    - mlthoughts2018 8y ago
      The incentive is just if they want the project to survive and thrive and continue. They may not want this, or may value their pleasure of hacking on it higher than long-term liveness. I’m not making any normative judgments about _whether_ they want one set of preferences or the other, only commenting that it turns out (normatively) badly, from the perspective of the community around the project, if they don’t prioritize the overall liveness of the project (which comes at the cost of “doing as they please”).
Sujan 8y ago
I think core developers should do whatever they want. Nobody is entitled to anything from a developer of an OSS project, unless there is a contract and/or money involved.
- mlthoughts2018 8y ago
  I think they have every freedom to do what they want. It will just turn out badly if they use that freedom to choose a walled-garden approach that expresses ambivalence to both user support and on-boarding new contributors by giving them tasks with visible impact and reasonable amounts of creative autonomy. I only care about what core devs “should” do from the perspective of “what keeps a project healthy.” If someone wants to optimize that choice for something else, like their personal enjoyment of hacking on a new feature, I think it would have unfortunate consequences, but other than stating my feeling about that, I couldn’t care less and it seems irrelevant to the discussion. That’s why I characterize it as an ego problem. As far as the whole rest of the project and user base is concerned, what some particular person wants just doesn’t matter. Yes, they’re free to make their choices that way. Then it just takes that particular case out of the discussion we’re having here about providing user support.
- blihp 8y ago
  A perfect example is the TensorFlow project's support policy which the article references (i.e. they don't do support.) As long as a project is clear about what they will and won't do/provide, just about anything is workable. Far worse to claim to provide support and then be inconsistent about it... better to either say 'we don't provide support' or 'contact us for support options and pricing'.
  - mlthoughts2018 8y ago
    TensorFlow is a very bad example of exactly the failure mode I’m talking about. In professional deep learning, TensorFlow is very widely regarded as a mess, with hostile developers who make breaking changes without warning and refuse to fix huge usability problems, let alone add important enhancements or support-specific bug fixes. Nobody seriously uses TensorFlow without Keras, except in situations when they have to make custom modifications precisely to support broken things that the core devs won’t fix. Contrast this with Keras and it’s night and day. Keras actually has support guidelines and a GitHub project and, even if lacking capacity, actually cares about its users instead of being willfully hostile to users like TensorFlow is. The original creator of Keras, Francois Chollet, can even be found very often in GitHub issue threads assisting totally novice newcomers to Keras and explaining tips and tricks with custom layers, etc.
kanox 8y ago
This is absolutely awful. People start projects because they want to spend their time coding, not tech support or teaching. Why do you want to make coders stop coding? Fuck you!
- dang 8y ago
  We've banned this account for breaking the site guidelines and ignoring our request to stop. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

thrower123 8y ago

> Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. At this point you need management and support staff. Trying to pound square peg developers into those round holes is rather hopeless, especially when it is free work not paid.

mlthoughts2018 8y ago
Sure, I agree it’s still logistically challenging. I’m just claiming the hard part is the ideological hurdle of getting the original core devs of the project to willingly facilitate frequent “changing of the guard” where the burden of critical new features and design is wholeheartedly given to new and intermediate developers of the project, to graciously let other people take the reins and have the core devs with an attitude of service to their community of users, fixing bugs, adding small feature enhancements, and particularly creating excellent documentation and tutorials. That’s the first step. Templates, disqus boards, SO, etc., aren’t going to save you if the core devs view the open source project as a walled garden where they pick and choose what to work on based on a need to “be the one” who is responsible for milestones of implementation.
- thrower123 8y ago
  What's the incentive to those developers to take on this pain-in-the-ass corporate kind of work, rather than just doing the work that they enjoy that made the project noticeable in the first place? Nothing is owed to anybody, if it's being made into unpleasant management work, you can just pick up your ball and go home and do something else. I'm not really sure I want new developers doing core work on a project, and would be somewhat skeptical of projects that did adopt such practices without heavy oversight.
  - mlthoughts2018 8y ago
    The incentive is just if they want the project to survive and thrive and continue. They may not want this, or may value their pleasure of hacking on it higher than long-term liveness. I’m not making any normative judgments about _whether_ they want one set of preferences or the other, only commenting that it turns out (normatively) badly, from the perspective of the community around the project, if they don’t prioritize the overall liveness of the project (which comes at the cost of “doing as they please”).

Sujan 8y ago

I think core developers should do whatever they want. Nobody is entitled to anything from a developer of an OSS project, unless there is a contract and/or money involved.

mlthoughts2018 8y ago
I think they have every freedom to do what they want. It will just turn out badly if they use that freedom to choose a walled-garden approach that expresses ambivalence to both user support and on-boarding new contributors by giving them tasks with visible impact and reasonable amounts of creative autonomy. I only care about what core devs “should” do from the perspective of “what keeps a project healthy.” If someone wants to optimize that choice for something else, like their personal enjoyment of hacking on a new feature, I think it would have unfortunate consequences, but other than stating my feeling about that, I couldn’t care less and it seems irrelevant to the discussion. That’s why I characterize it as an ego problem. As far as the whole rest of the project and user base is concerned, what some particular person wants just doesn’t matter. Yes, they’re free to make their choices that way. Then it just takes that particular case out of the discussion we’re having here about providing user support.
blihp 8y ago
A perfect example is the TensorFlow project's support policy which the article references (i.e. they don't do support.) As long as a project is clear about what they will and won't do/provide, just about anything is workable. Far worse to claim to provide support and then be inconsistent about it... better to either say 'we don't provide support' or 'contact us for support options and pricing'.
- mlthoughts2018 8y ago
  TensorFlow is a very bad example of exactly the failure mode I’m talking about. In professional deep learning, TensorFlow is very widely regarded as a mess, with hostile developers who make breaking changes without warning and refuse to fix huge usability problems, let alone add important enhancements or support-specific bug fixes. Nobody seriously uses TensorFlow without Keras, except in situations when they have to make custom modifications precisely to support broken things that the core devs won’t fix. Contrast this with Keras and it’s night and day. Keras actually has support guidelines and a GitHub project and, even if lacking capacity, actually cares about its users instead of being willfully hostile to users like TensorFlow is. The original creator of Keras, Francois Chollet, can even be found very often in GitHub issue threads assisting totally novice newcomers to Keras and explaining tips and tricks with custom layers, etc.

kanox 8y ago

This is absolutely awful. People start projects because they want to spend their time coding, not tech support or teaching. Why do you want to make coders stop coding? Fuck you!

dang 8y ago
We've banned this account for breaking the site guidelines and ignoring our request to stop. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.