Comment by mlthoughts2018 | Hacker News Reader

Comment by mlthoughts2018 | Hacker News Reader

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.

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

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.

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.

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

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.

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.

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

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.

I don't disagree, I find support across the board for Google products dismal. But isn't it better that they say 'we don't do support' than hold out hope that they might or provide spotty support? That way developers and users of the products, including TensorFlow, know what they're getting into. For the free projects that actually do provide good support, that's excellent and kudos to the developer/community that do so... they seem to be the exception these days.

I compare it to the 'old days' of software: it used to be common to have a phone number to call. Then it became email only and people complained there should be a support phone number. Then it was $0.99 apps and maybe you got a support forum. Now in the era of freemium, you're lucky if you get an online community support forum... and people complain when nobody monitors it. When you move to free, the support budget goes to $0 which leaves developers to shoulder support in addition to everything else. Unsurprisingly, many don't want to do this. If you're willing to pay, sure you can still get anything you want (up to and including on-site support for enterprise stuff if you have deep enough pockets) but as long as the default support model is clear at least one can make an informed decision. Support is one of those things that the $300+ (phone support), $30+ (email support), $10- (forum?), $0 (good luck) pays/paid for after all...

I guess I do agree with you that it’s better for a project to brazenly denounce support than to feign an effort.

In the case of TensorFlow in particular, it allows forward thinking people to realize it’s not a safe project to bet the farm on at all, not even anywhere close, even without factoring in Google’s tendency to sunset projects regardless of their relative success or community needs.

This is why nobody’s using it. Keras gives you the option of other backends, and there’s a large shift to PyTorch as well. Even being new and not as featureful, you simply just cannot stake the long term health of a project on the constant rug pull that is TensorFlow.

Reply on news.ycombinator.com