Hacker News Reader

> Yep, the problem is cultural. The whole system of reciprocity is out of whack. The system would work more smoothly if more people took on responsibilities, QA'd, contributed patches. Give engineers a % of time to contribute back to the libraries they use.

I think this need not even be framed just as "the moral thing to do" - in an environment where attracting quality engineers is a continuous challenge, small "sacrifices" like this can be far more effective than spending the same amount of money on raising the potential wage. If a job lists "contribute to Babel maintenance one <time unit> every <time unit>" as one of the responsibilities, that'd make me far more interested.

> Yep, the problem is cultural. The whole system of reciprocity is out of whack. The system would work more smoothly if more people took on responsibilities, QA'd, contributed patches. Give engineers a % of time to contribute back to the libraries they use.

It's more nuanced than that I'm afraid. I work on tooling for a living, and have in fact tried to contribute back to babel but unfortunately there's so much noise and traffic that there's just as good a chance that your PR is stuck in limbo forever than being merged or even reviewed. I understand why, there's only so much the maintainers can do with the limited time they have, but my point is that you can't just say that the problem is that people aren't contributing. It's a two-way street, and maintainers need to figure out how to actually accept (or reject) contributions as well.

There are other ways to contribute than opening PRs and issues of course, like sending money. But even sending money isn't without complexity -- plenty of companies have the ability to contribute financially, but they can't because they need a VAT receipt or invoice to make it happen. Accounting is a hard requirement for companies, you can't just send money willy-nilly like you can as a private person. It's surprisingly difficult for companies to contribute financially to most projects, and that's not even considering the hard ship of getting those expenses signed off which is often a battle and a half on its own. Babel has a decent set up, but still requires a credit card -- this alone makes it much harder since you'd probably have to personally expense it and then try to get it past accounting.

It's a problem, for sure, but I don't think it's as black and white as you make it seem.

> I work on tooling for a living, and have in fact tried to contribute back to babel but unfortunately there's so much noise and traffic that there's just as good a chance that your PR is stuck in limbo forever than being merged or even reviewed.

I agree it's a two way street and not all maintainers want to be "purely" what people consider a maintainer role unlike me - but it's a lot of responsibility on their part to have to look at every PR in a certain amount of time. I think contributors could also do more to ask and get involved although it will take more energy on both sides parts: like doing a hangout/video call etc even though it feels like people either maintainer or contributor just think making a PR suffices to get something merged when a lot of times it is so much more.

I think what I'm saying is that if you do get the time to make a PR and if employers allowed it, they should also allow for the time it takes to get through the noise and traffic by helping out with maintenance, not just the bug fixes, or that we need a priority kind of thing so that maintainers/contributors see effort from one another to make it better. Yeah it's definetely not that simple but I think we need more people/companies trying it out to really see what the problems are then just talk about it.

I agree, but as a contributor there’s only so much you can do if the receiving end isn’t, well, receiving.

Plenty of people try to contribute but either the receiving end is unreasonably difficult to work with – or, as is perhaps more often the case – simply aren’t responding at all. It’s hard to get on a call where the other end isn’t picking up, as it were.

I’ve seen this first hand several times. Despite numerous attempts to make things as easy as possible to merge, providing ample documentation for the changes, making yourself available etc., the receiving end simply isn’t picking up. At some point you just give up and let it be. Sometimes, I’ve seen my PRs get picked up months or even over a year after initially submitted, at which point even I as the author don’t know what the PR is all about anymore...

The idea that Babel -- which I love and think has had an immeasurably positive impact on the front-end community -- is anywhere near as valuable to an individual company as their database is completely out of touch.

A database, for many many companies, is essentially the business. There's nothing more important. Babel, which again I love, at the end of the day lets you write more expressive code. Anyone who thinks fixing a bug that lets you write arrow functions instead of using `Function.prototype.bind` or whatever, is anywhere as important as a database... is just wrong.

Always remember your place. Your job is to make widgets for a company. Your productivity definitely has value, but don't overestimate how much value it has.

A better example would have been something like Resharper, which companies are willing to pay for, but they won't make its bugs an important part of their roadmap.

>This is convenient.

Understatement of the year. It's not just convenient, it's an absolute gamechanger.

JS gets a shit reputation for being mountains of config before you can do any work, but because of `babel-preset-env` I can start a new project, put `> 5%` in the babel config, and write in the latest and greatest version of JavaScript and have it just work.

>JS gets a shit reputation for being mountains of config before you can do any work

But... that has nothing to do with JS and everything to do with the unnecessary complexity added by the ecosystem.

Are developers no longer aware that they can literally just open any text editor and write JS and it will work? That no one actually has to use NPM or Babel or anything?

Everyone is fully aware of that, just like how you can open a text editor and write a bash script that will work too.

But building an entire application like that would be insane!

There's websites, and there are web-applications, just like there are small scripts and there are full "applications". Yelling about how it's unnecessary complexity that someone made a python3 program with pip, tox, pyGTK and more when you could just open a text editor and write python 2.7 sounds silly doesn't it? Would you go to the maintainers of a large C project and tell them that CMake is unnecessary when they can just compile from the command line? Or just use make?

You can do that, but having these extra tools, this extra complexity pays off later when the application is larger, or when it needs to be maintained for many years.

Yes, I could just open a JS file and write JS, and I do for some websites, but for larger full applications, I want to use the newer language features, I want a compiler that will translate my code into something that all browsers can run, I want a compiler/linker that can do tree shaking and reduce the code size, I want a framework that makes it easier to architect a full application, I want a CSS module system to help manage the complexity of styling, I want a minifier that can optimize and reduce the size of my code, I want a unit testing framework that can help me prove my code is correct, I want to write in a dialect of javascript that can do type checking, I want a system to compress images to their smallest size for performance during the build process, I want to use packages that others have written, I want to have a cross platform task runner that makes it easy to develop, I want a "hot-reload" system which makes iterating through changes significantly faster, etc...

I want all of that, because the extra hour or 2 setting something up now will pay off when I need to maintain this application for the next decade or more.

My point is that javascript the language doesn't justify the absurd complexity of the ecosystem that's developed around it.

A statement like "JS gets a shit reputation for being mountains of config before you can do any work" put my teeth on edge a bit because there's no good reason for that to be the case, given how simple the language is.

> It goes to show how poorly funded open source projects are.

It's also completely unsurprising.

Relying on people's good will doesn't work sufficiently. It turns into a tragedy of the commons situation with everyone hoping to get the benefit of the work of others.