This guy is way more generous than I am. I would have yanked the whole project from the internet ages ago. Some big company would take over or launch a new project to protect their bottom line, probably paying an entire team of developers a lot more than they would have ever needed to donate to him. And I wouldn’t have a single shred of guilt about any of it.
I don’t even believe corporations are doing this on purpose to kill individual-driven open source. I just don’t think they care. They have no financial incentive to care. The aforementioned cost of $BIGCORP funding a replacement project with an entire team of developers compared to donating a pittance to this poor bastard? A rounding error on their quarterly financial reports. Why would they care?
Ever since spending some time maintaining something small, I’ve long dreamed of dual-licensing, with a free-license clause allowing revocation in the case of abusive behavior towards maintainers.
There would be something deeply satisfying about forwarding some trolls abusive messages to the legal department of their employer, explaining that the employer is no longer in compliance with the free license because they employ this person.
i think it is all about having a “throat to choke”, as one boss I had crassly put it. You use open source, it causes problems. No one is blamed. No one gets in trouble (for the most part). “You got it free? what did you expect?” is a safety net for a lot of people, even managers. Hire a team, pay their salary and benefits, and they don’t deliver? Well, there are lots of bottoms to be spanked (to stick with the crassness for continuities sake). Open source exposes the beauty and ugliness of human nature/incentives. Besides people have integrity, and taking their responsibilities seriously no matter their link on the chain, things will keep being just “meh”.
I’m amazed by the strength some people have to deal with all this toxicity in their lives, yet be able to push through it all and keep doing with they believe in. This would be many times past my breaking point.
I find the way “open source” maintainers are treated deplorable, and have so much sympathy for Denis and the situation he is in. That’s not something I would want for anyone, let alone the hard-working, underpaid maintainer of a great project. This article, however, is deeply disingenuous because it ignores the primary reason why most software companies are unable in any good faith to pay Denis for his work: he lives in the Russian Federation, a state which has been sanctioned by most of the world’s wealthiest countries in response to a genocidal attempt to annex its neighbour. Nobody can blame Denis for this, but it is a fact that sending money to him means financing that war, and in many countries, quite possibly breaking the law.
Open-source should be out of politics.
No, it shouldn’t. Every program you write has direct and indirect political consequences, and ignoring that fact makes you naïve, not impartial.
I don’t want to choose between two kinds of evil.
Which two kinds of evil? The kind of evil that wants to remove an entire country from the map, and… the equal and opposite evil that wants to stay alive? As soon as you buy into this “both-sides” narrative, you lose any hope for a constructive conversation and resolution, because – and I repeat – the fundamental problem here is that it would be immoral and possibly illegal to do what Denis is asking, even if the immediate benefit to Denis would be positive.
I understand that, I’ve been there myself. But nobody forces anybody to state that there are “two kinds of evil”, when there patently are not two kinds of evil.
(Also, the notion that family and friends are likely to suffer legally as the result of one speaking out is a bit dishonest – this simply isn’t a common occurrence.)
I was going to say something similar, but he also overtly accuses the state of corruption with respect to the handling of his accident. Beyond that, habitually ignoring politics is kind of what got ordinary Russians into this situation to begin with.
I agree with @albino, that there aren’t two kinds of evil in this situation and there was no reason to bring this equivocation into the discussion.
You have to bring it into the discussion somehow, though, because it is central to the author’s point: he is asking people to pay him, but there is a massive moral dilemma overshadowing that request, and he responds by claiming it’s not up for discussion. (I am being charitable here by not interpreting “both sides” as a dogwhistle, which it usually is.)
The sooner the RF loses the war it started, the sooner we can pay Denis the salary he deserves. I don’t think there’s any use in skirting over that fact.
The word “genocide” has a meaning. It’s harmful to water it down so much that what Russia is doing, as despicable as it is, is called “genocide.”
There is no evidence that Russia has been systematically murdering Ukrainians for being Ukrainian. Have they started a war of aggression? Yes. Have they targeted civilians? Yes. Do I wish Putin could experience a tenth of the misery he has inflicted in his life? Yes. Have the Russians systematically murdered people for their identities? No.
Truth is always the first casualty of war, but it’s still very sickening to me to see people think that they don’t need to care about facts anymore once we’re talking about Russians. It was wrong to say the Huns were slaughtering Belgian babies; it was wrong to say Iraqis were slaughtering Kuwaiti babies; it is wrong to say that Russia is conducting a genocide. Let’s speak the truth now, so people will believe us when we speak the truth about their crimes later.
This is not the right forum for this conversation, but the Convention on the Prevention and Punishment of the Crime of Genocide, which was adopted by the UN General Assembly in 1948, explicitly lists “forcibly transferring children of the group to another group” as a form of genocide, and this is a practice Russia has obviously committed since the start of this war. You can read more about the Genocide Convention on Wikipedia, as well as Russian child abduction in this conflict. This is not “watering down” the term.
Such people, “the majority of the population,” so more than twenty million people, are to be killed or sent to work in “labor camps” to expurgate their guilt for not loving Russia. Survivors are to be subject to “re-education.” Children will be raised to be Russian. The name “Ukraine” will disappear.
I have spent a long time thinking and reading about this, and come to the conclusion that “genocide” is probably the right term to use here. Just as for you, using the term waters down its meaning, for me, not using it would mean watering down the scale of crimes committed.
That said, I entirely understand where you’re coming from, respect your position, and don’t want to start a genocide definition debate on a technology forum! We both have a common understanding of what’s happening and find it appalling – the use of the g-word is a deliberate choice by me, but I hope you can appreciate my point even if you don’t agree 100% with the language I used to make it.
FWIW, there is a huge article by a prominent Ukrainian human rights activist about the problem, which invokes relevant international laws and causes to argue that what Russia does can be qualified as genocide by the rule of law. Unfortunately, it is in Ukrainian, IDK if Google Translate will be adequate enough (but I can say that it is pretty far from handwaving “it is bad, therefore genocide”).
What Russians are doing is not just conquering war. They are targeting the Ukrainian identity as a whole (by, say, relocating children from occupied territories by force and “re-educating” them to be good Russians). IANAL, though, and the discussion of whether “genocide” is an appropriate term is quite complicated, but it is hard to say the term is inappropriate altogether.
Have the Russians systematically murdered people for their identities? No.
On territories they’ve managed to occupy, that’s pretty much what they do. Either this or forcing to explicitly abandon the identity. As far as I understand, there is enough evidence of that.
You’re right in all details, but this is one of the things you’re not allowed to talk about. The enemy is always not only evil, but ontologically evil.
The increasing frequency of stories of open source maintainers becoming burnt out, largely driven by the burden of supporting users from large companies, seems like a ringing endorsement of GPL style licenses to me.
Many large companies are averse to using GPL licensed software. If an open source maintainer is overburdened by the demand placed on them by companies which have no desire or willingness to contribute in any way (either financially or otherwise), the GPL may scare them off.
Sure, your project may not get as “popular”. But maybe that’s a good thing. At least until we can figure out a model for fairly compensating open source maintainers for their time and effort.
I really like and hate the things companies like Obsidian are doing. Free for personal use. Paid licence for commercial use. I like it because it fixes this particular problem. I hate it because it sounds like what microsoft was for so long by pushing “free” windows on schools and governments and everything else, so the companies were practically forced into paying support.
It doesn’t just sound like it, it’s the same thing. Would also be surprised if it increases adoption or contribution - Obsidian “contributors” are now giving free labour to Obsidian’s commercial product, and businesses will just adopt the free thing, use their own, or (more often than not) decide they simply don’t need it anymore.
In my experience of maintaining popular OSS projects, the abuse comes from individuals rather than from a corporate policy. It’s the employees who want to take on a 15,000 line dependency just to avoid rewriting 100 lines of it, and it’s them who get indignant when something isn’t to their liking that makes their work a bit harder. Corporate policy would much rather just rewrite those 100 lines in-house and not worry about it ever again.
I’d like to think that having very clear boundaries about engagement and strongly encouraging forks is maybe a viable solution for maintainers who don’t want to deal with it? I’ve had a few projects where in their lifetime I limited reported issues only to critical bugs, disallowing new features, encouraging independent forks (even linking to them). I think that’s a fine approach, regardless of license.
As for getting financial support, I genuinely don’t believe there’s any alternative [in today’s society] to Doing Sales/Business Development – doing cold calls, getting intros, putting together proposals, understanding customer needs/budgets/accounting structures, following up aggressively, keeping at it for multiple quarters at a time. Whether it’s hustling to get grants/sponsors, or closing consulting retainers, or something else. It requires a lot of time, effort, and motivation – it’s a type of business, and it needs to be operated as such to be profitable.
I’d love to live in some future society where there are more structural alternatives, though.
Looking at the possibilities described by the author, it seems they do not envision the possibility of selling support contract. Do not produce a commercial version: simply explain that you won’t provide features, bug fixes or support to users who do not have a support contract. Everything else is best effort.
Of course companies are not going to “contribute” unless they have to. First reason being that you lead/manager/director does not have the legal option to make donations to external individuals. But they have a budget which can be used for support contracts.
core-js is not a several lines library that you can write and forget about it. Unlike the vast majority of libraries, it’s bound to the state of the Web. It should react to any change of JavaScript standards or proposals, to any new JS engine release, to any detection of a bug in JS engines, etc.
If nobody cares about it because it is just a polyfill, then the author should just either stop maintaining it, or doing what he want with it and ignore everything else. If this is actually important, if core-js not being updated causes problems to companies using it, then selling a support contract absolutely makes sense. Of course it means having to do some marketing, contacting companies directly, but there’s no free money.
As an example, I’ve worked at companies who used Sidekiq, and paying for the Pro version was a no brainer. Features, support, companies will pay for it if they need it. But you need to sell something, not just ask for money.
But there’s no extras to sell, no room for special treatment for paying customers. It has one goal and it does it really well. There’s only been a few dozen bugs in over a decade. It’s a lot of work but the work is extremely obvious and easily tested.
I think they meant more in the sense of Redhat vs CentOS Linux (well, as it was a while ago). You wanted rock-solid commercally developed Linux? Get CentOS. You also wanted support for when the shit hits the fan? You pay Redhat licence for the same code, but you kick the problems can down the road.
I think that’s something that all OSS developers (at least the ones that hope for a financial support) should understand. You need to give your users, however little, an excuse to pay you, otherwise they might be as helpless as you are in convincing their management. Even the management themselves might be helpless, because they might not be able to justify cashing out randomly while they’re themselves ultimately responsible to the shareholders.
As an employee, it’s a needless waste of social capital for me to ask a superior to donate, say $500 to a project we use, but it’s very easy to ask for a minor purchase of $500 that will marginally increase my (team’s) productivity.
A large chunk on the blame for the entitlement and spite towards someone working for a relative pittance I believe falls on Eric S. Raymond & Bruce Perens’ “Open Source Initiative”, and their work to try and build a cartel around certifying open source software. Their lack of success precedes zloirock’s, by laying the foundation for a software culture inspired not by sharing, but by entitlement and exploitation.
How sad. Also weird he’s getting defrauded by Tidelift, but I’m no lawyer.
Tidelift is a US organization, and it’s quite true that financial transfers between US and Russian entities are not readily available right now. Sanctions against Russia affect Russian citizens, and while I’m not a lawyer, economist, or politician, I assume that’s by design. A war is fought on many fronts, and war is hardly ever fair.
Probably not defrauding him, but Tidelift customers. The post shows a screenshot where they say he’s getting the money that you pay to Tidelift for core-js, but states that he isn’t getting that money.
If that’s the case, then they are commiting fraud.
I appreciate and am grateful for the work Pushkarev did on core-js. I used it in several projects. As I recall, for much of that time, the compensation he requested was employment. Every project with core-js as a dependency would show a message saying he was “looking for a good job.” At one point, when my company was hiring, I looked him up to see if there was a good fit, but learned he was in prison. There wasn’t much I could do to help him at that time.
A lot has changed in the browser landscape in the intervening years. Unfortunately, his pleas for work and later, compensation, have grown in inverse proportionality to the value of core-js. Perhaps I’m oversimplifying, but I think the origin of its popularity was IE 11. core-js was included either as boilerplate in scaffolding or added as an afterthought to keep the people who signed the checks for software vendors happy. Anecdotally, check-signing corporate types were 100% of the IE 11 users I encountered in the 2010s. Now that IE 11 is officially dead (and unofficially dead for much longer than Microsoft says it has been), and as I reflect on the time I spent fixing bugs caused by dueling polyfills (even if core-js was the better one), I’d sooner take direct responsibility dealing with idiosyncrasies between browsers’ JavaScript implementations in my own source code or maybe use the occasional ponyfill rather than continue to use polyfills like core-js. I’ve already started to do this in both my personal and professional projects. I would frankly go as far as to say that the presence of browser polyfills and even Babel transforms in project scaffolding in a post-IE 11 era is a code smell.
Pushkarev’s story reminds me of a guy I knew in college who used to cut his neighbors’ hair for free. I think he did it to make friends. Then, over the summer, when everyone had left campus and quite forgot about their free haircuts, he wanted new electric clippers and asked his neighbors for compensation to help pay for them. I heard about this when I came back the next school year. These neighbors rolled their eyes and complained loudly to me about how they shouldn’t be made to feel guilty about something that was given to them free. They remarked sarcastically that it didn’t bode well for a business major to have such a bad business model. Their attitude toward him grew resentful and surly. It was tragic and, I think, avoidable.
I’d sooner take direct responsibility dealing with idiosyncrasies between browsers’ JavaScript implementations in my own source code or maybe use the occasional ponyfill rather than continue to use polyfills like core-js.
I’m curious, what are the technical reasons behind this? What would have been better by writing the polyfills yourself as opposed to a widely-tested one? You mention conflicting polyfills - can you describe a particular case of that?
I’ve already started to do this in both my personal and professional projects. I would frankly go as far as to say that the presence of browser polyfills and even Babel transforms in project scaffolding in a post-IE 11 era is a code smell.
For one type of projects I would almost agree. but I don’t know that I’d declare it a smell out of the box. Right now you’d not be polyfilling for many features in a typical smaller project, perhaps some of the new Intl stuff. But anything post-IE included, for a while, things like async functions, dynamic imports, optional chaining etc as far as I remember. It’s not that you can’t write code without those, but we could write cool websites with ES3 as well - it’s just nicer this way.
They remarked sarcastically that it didn’t bode well for a business major to have such a bad business model. Their attitude toward him grew resentful and surly. It was tragic and, I think, avoidable.
Yes, some of us have the programming chops, others have business chops. Sometimes people are good at both.
I work with clients who use Magento, an open source ecommerce platform. The last time I had a problem with dueling polyfills, Magento shipped with the long deprecated es6-collections. If memory serves, es6-collections has a broken implementation of Map. Our integration code was bundled with core-js and loaded after es6-collections. core-js defers to existing global APIs, regardless of whether they’re native (which is not to say that discerning native implementations is a trivial problem). Our integration broke in IE 11 because it depended on Map being polyfilled correctly.
Diagnosing the problem with the IE 11 debugger over BrowserStack took a couple of days. It was a complex WebGL integration with a lot of dynamically loaded code running in an environment we didn’t control. Changing the load order was not an option. We were too far down the polyfill road on our end to replace core-js with ponyfills or some other, less deferential polyfill library without putting all our other client integrations at risk. The Magento contractor quoted an outrageous price to replace the broken polyfill on their end. That left the client with little choice but to give up on IE 11 support. The issue came up one or two more times with other Magento clients as well. That was probably the last nail in the coffin for IE 11 support at our shop. The first lesson I drew was that Magento used the wrong polyfill and was entirely to blame. After further reflection, the more valuable lesson I drew was that no one should have be using polyfills in the first place. Polyfills are an antipattern because they modify APIs they don’t own. I initially thought the ponyfill.com manifesto a bit puritanical, but having been burned a few times now, I’ll never use a polyfill in a new project again. We only ever used core-js in the first place because it shipped with Vue CLI’s scaffolding at the time. If I had to do the last few years over again, I would find a way to keep it out and use ponyfills instead.
Another problem with polyfills—one that Pushkarev wants to solve if he gets funding—is reducing the bloat they cause. One of his proposed solutions is akin to polyfill.io, where a browser gets served only the polyfills they need. But that’s an extra network round trip every browser has to make, and for features the code may not even be using. And for what benefit? To support a dead browser? To keep all browsers at the bleeding edge of the JavaScript API at all times? No, I think it’s time to simplify. I’ve stopped using JavaScript features that aren’t supported by the browsers we’re targeting. I’ve configured TypeScript and eslint in projects I work on to prevent anyone from accidentally using them. It just works.
You probably know this already, but it’s worth emphasizing that core-js does not polyfill async nor any other syntax features. Those require Babel transforms. I’m not particularly keen on Babel in a post-IE 11 era, either. Babel-generated async code is difficult to debug and the more the code is transformed from its original, the less likely breakpoints are to line up with the source. This is very different from TypeScript’s erasable type system, which yields very accurate source maps, working breakpoints, and call stacks that more closely resemble the source.
The hate mail people sent to Pushkarev was unwarranted as it was abusive. I don’t begrudge his advertisements in npm messages over the years. I don’t blame him for the war or his claimed neutrality. But I do feel weird about sending money to Russia right now. I wish the best possible future for him, but I don’t think it’s in core-js. Hopefully he can find a way to emigrate in spite of the accident, because it doesn’t seem like it’s in Russia, either.
Given this difficult to read story, and author’s struggle in industry/skill combination, where should have been none – there are lessons here for the whole community.
My personal takeaway from this is, is that package hosting repositories (and the related package managers), are in the position today, to improve the compensation/support model for OSS developers.
Here are some ideas:
a) if a package needed funding is referenced directly, always display funding request, without additional commands (without npm fund)
b) if a package depends on package with a funding request, same as in ( a )
c) a funding request needs to have per-user request, per annual amount. This is to normalize the requests, does not preclude other methods of support. Is that just at least one of the methods of support should be clear and normalized
d) if there are multiple packages that, in effect, trigger (a) or (b) display one line noting number of packages, and the total normalized funding request.
e) If the is a package that requests funding, that depends on another package that requests funding – the should be an indicator that says a given package requests funding, and it relies on other packages that request funding. this is just to indicate that this condition exists
f) the funding goal had been reached for a year, there should be an indicator for package saying that the goal is reached, but the funding info as triggered by (a) or (b) should still be displayed (I am not sure how this is calculated, this can be done in different ways, so just including this for completeness).
h) If there is same maintainer for the same package in different programming languages, they should use the same funding request ID and other shared attributes, so that a contributor can see how their support works (or does not) across all the related packages.
g) There is probably a need to categories open source packages with funding requests as
stand-alone 2) satellites 3) educational-only
1 - means that the package provides functionality that does not require presence of a commercial product
2 - means that the package provides functionality that requires presence of a commercial product
3 - is that it is not production ready, but is meant as a tutoring aid (eg books, or samples, or project starters/boilerplates)
–
Overall the above is aimed to create uniformity and particular ‘request marketing model’ that may serve a number of OSS developers better, especially if they are in a disadvantaged personal or economic or geopolitical situation
Oh, at first I think this would be abused easily, but perhaps not. The trouble is, who’s determining the funding goals? Whos’ the determining which package is “worth” more? I’d be happy to dump costs of doing all this on Microsoft, or whoever is hosting the code repo, I would say that they get more then enough through telemetry gathered, but it would be unfair both to them and to us - why should one commercial company be in charge of distributing funds?
I think most of the issues would be solvable. Good ideas, in any case.
thank you.
I did not mean that gihub repo owner is involved.
I rather meant the NPMjs.com folks, and others that manage maven, php, perl, python (pypi.org) and such.
Also they do not need to distribute funds (they could though). Instead, I think standardized funding method could be an appropriately sanitized link.
I was trying to ideate for a workflow that has normalized (uniform) representation funding requests in package ecosysytems where there deep dependency trees and only top-level dependencies (eg in package.json) are not easily surfaced for final solution developers.
In the case of core-js, it is rarely (in my limited experience) used directly as a dependency in package.json that developers at those commercial organizations mentioned in the article’s example are used, instead these kinds of packages are used inside by some other package (often serveral level deep).
It’s rubbish to have people treat you like shit when you ask them to pay for your stuff, but that kinda is open source. If you want to get paid you need to do a lot of marketing and/or license your stuff more restrictively.
I don’t think it’s very cool to be blaming the families of the people that you ran over for your financial troubles, tho.
Perhaps I’m wrong, but I didn’t get the feeling he was blaiming them for his troubles. It seemed to me more like explaining why he can’t leave Russia, because haters gonna hate, and dig that stuff out anyway, so he went upfront and explained. Like I said, I could be wrong though.
The problem with this is that it will invite abuse from entitled assholes like the core-js post is full of screenshots of. “Ridiculous, please turn this spambot off, I’m going to report this behavior to GitHub”
JavaScript, like other Smalltalk-family languages, exposes pretty much everything to reflection. This means that there’s a very blurry line between the standard library and user code. User code can replace the global objects or methods on them that were provided by the standard library. You can effectively replace the entire standard library with your own implementation (modulo things that talk to the outside world, though you can replace these with wrappers).
A polyfill is named after the goo that you use to repair cracks in the walls (which tends to have different names in different locations even in the English-speaking world. Bill Bryson’s Notes from a Big Country discusses his problems trying to find the local name after moving back to the US). The problem is that you want to use modern JavaScript features, but you also want to deploy to all browsers. The solution comes in two parts. A polyfill for the standard library, which covers the cracks and makes whatever the browser ships act like a modern version, and a transpires that converts modern JavaScript (or some other language) constructs into things supported by all browsers.
My understanding is that a polyfill is effectively a compatibility layer for individual browser APIs, if the current browser supports an API used by the application then it’ll call into the browser runtime, otherwise it’ll use a reimplementation of that API from the polyfill of it.
Pretty spot on, with one additional use case: support for new, unreleased features. There are JavaScript features that developers like to use that are not finalized yet and not standardised, so polyfills, hmm, fill a dual role there. One, provide access to those features before they’re standardised and implemented by all browsers, as well as testing out these things before the standard gets finalized (so if a particular feature doesn’t really work out, it doesn’t get standardised and implemented that way).
I flagged this as unkind, but then I felt I had to comment and it would not allow me to without unflagging.
Who is this message for? Is it for the author?
This could have been you. Congratulations that you made different decisions that worked out for you.
There is no clear path to success writing and maintaining open source. Your own path is not at-all guaranteed for other projects, and in fact might be put at risk if every OSS project took it. If yours had failed for your project would you have welcomed feedback that compared it to other failures and ridiculed it as insanity to expect something different?
Your comment here comes across to me as dismissive, rude, and yes: unkind. It also refers to absolutely nothing about this specific situation and acknowledges nothing that the author wrote. It plays in to how people mistreat maintainers.
This guy is way more generous than I am. I would have yanked the whole project from the internet ages ago. Some big company would take over or launch a new project to protect their bottom line, probably paying an entire team of developers a lot more than they would have ever needed to donate to him. And I wouldn’t have a single shred of guilt about any of it.
I don’t even believe corporations are doing this on purpose to kill individual-driven open source. I just don’t think they care. They have no financial incentive to care. The aforementioned cost of $BIGCORP funding a replacement project with an entire team of developers compared to donating a pittance to this poor bastard? A rounding error on their quarterly financial reports. Why would they care?
Agreed, I’d have stopped working on this thing long ago. The hate this guy gets is absurd and undeserved. I honestly don’t see why he puts up with it.
Ever since spending some time maintaining something small, I’ve long dreamed of dual-licensing, with a free-license clause allowing revocation in the case of abusive behavior towards maintainers.
There would be something deeply satisfying about forwarding some trolls abusive messages to the legal department of their employer, explaining that the employer is no longer in compliance with the free license because they employ this person.
i think it is all about having a “throat to choke”, as one boss I had crassly put it. You use open source, it causes problems. No one is blamed. No one gets in trouble (for the most part). “You got it free? what did you expect?” is a safety net for a lot of people, even managers. Hire a team, pay their salary and benefits, and they don’t deliver? Well, there are lots of bottoms to be spanked (to stick with the crassness for continuities sake). Open source exposes the beauty and ugliness of human nature/incentives. Besides people have integrity, and taking their responsibilities seriously no matter their link on the chain, things will keep being just “meh”.
Why would anyone care about a hypothetical project, if you – the hypothetical project’s autor – wouldn’t even care about it?
I’m amazed by the strength some people have to deal with all this toxicity in their lives, yet be able to push through it all and keep doing with they believe in. This would be many times past my breaking point.
I find the way “open source” maintainers are treated deplorable, and have so much sympathy for Denis and the situation he is in. That’s not something I would want for anyone, let alone the hard-working, underpaid maintainer of a great project. This article, however, is deeply disingenuous because it ignores the primary reason why most software companies are unable in any good faith to pay Denis for his work: he lives in the Russian Federation, a state which has been sanctioned by most of the world’s wealthiest countries in response to a genocidal attempt to annex its neighbour. Nobody can blame Denis for this, but it is a fact that sending money to him means financing that war, and in many countries, quite possibly breaking the law.
No, it shouldn’t. Every program you write has direct and indirect political consequences, and ignoring that fact makes you naïve, not impartial.
Which two kinds of evil? The kind of evil that wants to remove an entire country from the map, and… the equal and opposite evil that wants to stay alive? As soon as you buy into this “both-sides” narrative, you lose any hope for a constructive conversation and resolution, because – and I repeat – the fundamental problem here is that it would be immoral and possibly illegal to do what Denis is asking, even if the immediate benefit to Denis would be positive.
I’m willing to give him benefit of doubt that he doesn’t want to comment on the war due to what happens if you say something wrong.
I understand that, I’ve been there myself. But nobody forces anybody to state that there are “two kinds of evil”, when there patently are not two kinds of evil.
(Also, the notion that family and friends are likely to suffer legally as the result of one speaking out is a bit dishonest – this simply isn’t a common occurrence.)
Yeah I do agree, “two kinds of evil” does sound weird. There’s just one kind of evil there, the country that is attacking. That’s it.
There’s the evil Russia does on Ukrainians, and there’s the evil Russia does on Russians.
I was going to say something similar, but he also overtly accuses the state of corruption with respect to the handling of his accident. Beyond that, habitually ignoring politics is kind of what got ordinary Russians into this situation to begin with.
I agree with @albino, that there aren’t two kinds of evil in this situation and there was no reason to bring this equivocation into the discussion.
You have to bring it into the discussion somehow, though, because it is central to the author’s point: he is asking people to pay him, but there is a massive moral dilemma overshadowing that request, and he responds by claiming it’s not up for discussion. (I am being charitable here by not interpreting “both sides” as a dogwhistle, which it usually is.)
The sooner the RF loses the war it started, the sooner we can pay Denis the salary he deserves. I don’t think there’s any use in skirting over that fact.
I agree with you completely.
The word “genocide” has a meaning. It’s harmful to water it down so much that what Russia is doing, as despicable as it is, is called “genocide.”
There is no evidence that Russia has been systematically murdering Ukrainians for being Ukrainian. Have they started a war of aggression? Yes. Have they targeted civilians? Yes. Do I wish Putin could experience a tenth of the misery he has inflicted in his life? Yes. Have the Russians systematically murdered people for their identities? No.
Truth is always the first casualty of war, but it’s still very sickening to me to see people think that they don’t need to care about facts anymore once we’re talking about Russians. It was wrong to say the Huns were slaughtering Belgian babies; it was wrong to say Iraqis were slaughtering Kuwaiti babies; it is wrong to say that Russia is conducting a genocide. Let’s speak the truth now, so people will believe us when we speak the truth about their crimes later.
This is not the right forum for this conversation, but the Convention on the Prevention and Punishment of the Crime of Genocide, which was adopted by the UN General Assembly in 1948, explicitly lists “forcibly transferring children of the group to another group” as a form of genocide, and this is a practice Russia has obviously committed since the start of this war. You can read more about the Genocide Convention on Wikipedia, as well as Russian child abduction in this conflict. This is not “watering down” the term.
This is not the place to argue about genocide but if you want more perspective, let me recommend:
https://human-rights.cmc.edu/2022/04/14/russias-genocide-handbook/
And also this interview: https://www.powervertical.org/2022/04/22/the-case-against-vladimir-putin/
These are from very reputable sources. Whether these crimes will actually be prosecuted as genocide or not, we don’t know yet.
I have spent a long time thinking and reading about this, and come to the conclusion that “genocide” is probably the right term to use here. Just as for you, using the term waters down its meaning, for me, not using it would mean watering down the scale of crimes committed.
That said, I entirely understand where you’re coming from, respect your position, and don’t want to start a genocide definition debate on a technology forum! We both have a common understanding of what’s happening and find it appalling – the use of the g-word is a deliberate choice by me, but I hope you can appreciate my point even if you don’t agree 100% with the language I used to make it.
👍
Very nicely put.
FWIW, there is a huge article by a prominent Ukrainian human rights activist about the problem, which invokes relevant international laws and causes to argue that what Russia does can be qualified as genocide by the rule of law. Unfortunately, it is in Ukrainian, IDK if Google Translate will be adequate enough (but I can say that it is pretty far from handwaving “it is bad, therefore genocide”).
What Russians are doing is not just conquering war. They are targeting the Ukrainian identity as a whole (by, say, relocating children from occupied territories by force and “re-educating” them to be good Russians). IANAL, though, and the discussion of whether “genocide” is an appropriate term is quite complicated, but it is hard to say the term is inappropriate altogether.
On territories they’ve managed to occupy, that’s pretty much what they do. Either this or forcing to explicitly abandon the identity. As far as I understand, there is enough evidence of that.
You’re right in all details, but this is one of the things you’re not allowed to talk about. The enemy is always not only evil, but ontologically evil.
[Comment removed by author]
what a sad and soul crushing read :(
The increasing frequency of stories of open source maintainers becoming burnt out, largely driven by the burden of supporting users from large companies, seems like a ringing endorsement of GPL style licenses to me.
How would that help in this situation?
Many large companies are averse to using GPL licensed software. If an open source maintainer is overburdened by the demand placed on them by companies which have no desire or willingness to contribute in any way (either financially or otherwise), the GPL may scare them off.
Sure, your project may not get as “popular”. But maybe that’s a good thing. At least until we can figure out a model for fairly compensating open source maintainers for their time and effort.
GPLv2 might not do what you want, but GPLv3 sometimes does. I have a more complete listing of which licenses scare corporations; I personally choose AGPL or WTFPL.
I really like and hate the things companies like Obsidian are doing. Free for personal use. Paid licence for commercial use. I like it because it fixes this particular problem. I hate it because it sounds like what microsoft was for so long by pushing “free” windows on schools and governments and everything else, so the companies were practically forced into paying support.
It doesn’t just sound like it, it’s the same thing. Would also be surprised if it increases adoption or contribution - Obsidian “contributors” are now giving free labour to Obsidian’s commercial product, and businesses will just adopt the free thing, use their own, or (more often than not) decide they simply don’t need it anymore.
In my experience of maintaining popular OSS projects, the abuse comes from individuals rather than from a corporate policy. It’s the employees who want to take on a 15,000 line dependency just to avoid rewriting 100 lines of it, and it’s them who get indignant when something isn’t to their liking that makes their work a bit harder. Corporate policy would much rather just rewrite those 100 lines in-house and not worry about it ever again.
I’d like to think that having very clear boundaries about engagement and strongly encouraging forks is maybe a viable solution for maintainers who don’t want to deal with it? I’ve had a few projects where in their lifetime I limited reported issues only to critical bugs, disallowing new features, encouraging independent forks (even linking to them). I think that’s a fine approach, regardless of license.
As for getting financial support, I genuinely don’t believe there’s any alternative [in today’s society] to Doing Sales/Business Development – doing cold calls, getting intros, putting together proposals, understanding customer needs/budgets/accounting structures, following up aggressively, keeping at it for multiple quarters at a time. Whether it’s hustling to get grants/sponsors, or closing consulting retainers, or something else. It requires a lot of time, effort, and motivation – it’s a type of business, and it needs to be operated as such to be profitable.
I’d love to live in some future society where there are more structural alternatives, though.
Looking at the possibilities described by the author, it seems they do not envision the possibility of selling support contract. Do not produce a commercial version: simply explain that you won’t provide features, bug fixes or support to users who do not have a support contract. Everything else is best effort.
Of course companies are not going to “contribute” unless they have to. First reason being that you lead/manager/director does not have the legal option to make donations to external individuals. But they have a budget which can be used for support contracts.
Am I missing something?
It’s a polyfill. Either it works for everyone, or it doesn’t. There are hardly any bug tickets because of how simple yet crucial it is.
To quote the author:
If nobody cares about it because it is just a polyfill, then the author should just either stop maintaining it, or doing what he want with it and ignore everything else. If this is actually important, if core-js not being updated causes problems to companies using it, then selling a support contract absolutely makes sense. Of course it means having to do some marketing, contacting companies directly, but there’s no free money.
As an example, I’ve worked at companies who used Sidekiq, and paying for the Pro version was a no brainer. Features, support, companies will pay for it if they need it. But you need to sell something, not just ask for money.
But there’s no extras to sell, no room for special treatment for paying customers. It has one goal and it does it really well. There’s only been a few dozen bugs in over a decade. It’s a lot of work but the work is extremely obvious and easily tested.
I think they meant more in the sense of Redhat vs CentOS Linux (well, as it was a while ago). You wanted rock-solid commercally developed Linux? Get CentOS. You also wanted support for when the shit hits the fan? You pay Redhat licence for the same code, but you kick the problems can down the road.
I think that’s something that all OSS developers (at least the ones that hope for a financial support) should understand. You need to give your users, however little, an excuse to pay you, otherwise they might be as helpless as you are in convincing their management. Even the management themselves might be helpless, because they might not be able to justify cashing out randomly while they’re themselves ultimately responsible to the shareholders.
As an employee, it’s a needless waste of social capital for me to ask a superior to donate, say $500 to a project we use, but it’s very easy to ask for a minor purchase of $500 that will marginally increase my (team’s) productivity.
He really should talk to the owners of https://github.com/briansmith/ring and https://github.com/rui314/mold. They both have an open source product with a support contract model. Read this thread: https://github.com/briansmith/ring/issues/774. This is how you do open source business.
Though if you look at crates.io, it seems he’s not yanking anymore. https://crates.io/crates/ring/versions
A large chunk on the blame for the entitlement and spite towards someone working for a relative pittance I believe falls on Eric S. Raymond & Bruce Perens’ “Open Source Initiative”, and their work to try and build a cartel around certifying open source software. Their lack of success precedes zloirock’s, by laying the foundation for a software culture inspired not by sharing, but by entitlement and exploitation.
How sad. Also weird he’s getting defrauded by Tidelift, but I’m no lawyer.
Tidelift is a US organization, and it’s quite true that financial transfers between US and Russian entities are not readily available right now. Sanctions against Russia affect Russian citizens, and while I’m not a lawyer, economist, or politician, I assume that’s by design. A war is fought on many fronts, and war is hardly ever fair.
Probably not defrauding him, but Tidelift customers. The post shows a screenshot where they say he’s getting the money that you pay to Tidelift for core-js, but states that he isn’t getting that money.
If that’s the case, then they are commiting fraud.
Couple of important ideas in this space:
I appreciate and am grateful for the work Pushkarev did on core-js. I used it in several projects. As I recall, for much of that time, the compensation he requested was employment. Every project with core-js as a dependency would show a message saying he was “looking for a good job.” At one point, when my company was hiring, I looked him up to see if there was a good fit, but learned he was in prison. There wasn’t much I could do to help him at that time.
A lot has changed in the browser landscape in the intervening years. Unfortunately, his pleas for work and later, compensation, have grown in inverse proportionality to the value of core-js. Perhaps I’m oversimplifying, but I think the origin of its popularity was IE 11. core-js was included either as boilerplate in scaffolding or added as an afterthought to keep the people who signed the checks for software vendors happy. Anecdotally, check-signing corporate types were 100% of the IE 11 users I encountered in the 2010s. Now that IE 11 is officially dead (and unofficially dead for much longer than Microsoft says it has been), and as I reflect on the time I spent fixing bugs caused by dueling polyfills (even if core-js was the better one), I’d sooner take direct responsibility dealing with idiosyncrasies between browsers’ JavaScript implementations in my own source code or maybe use the occasional ponyfill rather than continue to use polyfills like core-js. I’ve already started to do this in both my personal and professional projects. I would frankly go as far as to say that the presence of browser polyfills and even Babel transforms in project scaffolding in a post-IE 11 era is a code smell.
Pushkarev’s story reminds me of a guy I knew in college who used to cut his neighbors’ hair for free. I think he did it to make friends. Then, over the summer, when everyone had left campus and quite forgot about their free haircuts, he wanted new electric clippers and asked his neighbors for compensation to help pay for them. I heard about this when I came back the next school year. These neighbors rolled their eyes and complained loudly to me about how they shouldn’t be made to feel guilty about something that was given to them free. They remarked sarcastically that it didn’t bode well for a business major to have such a bad business model. Their attitude toward him grew resentful and surly. It was tragic and, I think, avoidable.
I’m curious, what are the technical reasons behind this? What would have been better by writing the polyfills yourself as opposed to a widely-tested one? You mention conflicting polyfills - can you describe a particular case of that?
For one type of projects I would almost agree. but I don’t know that I’d declare it a smell out of the box. Right now you’d not be polyfilling for many features in a typical smaller project, perhaps some of the new Intl stuff. But anything post-IE included, for a while, things like async functions, dynamic imports, optional chaining etc as far as I remember. It’s not that you can’t write code without those, but we could write cool websites with ES3 as well - it’s just nicer this way.
Yes, some of us have the programming chops, others have business chops. Sometimes people are good at both.
I work with clients who use Magento, an open source ecommerce platform. The last time I had a problem with dueling polyfills, Magento shipped with the long deprecated es6-collections. If memory serves, es6-collections has a broken implementation of
Map. Our integration code was bundled with core-js and loaded after es6-collections. core-js defers to existing global APIs, regardless of whether they’re native (which is not to say that discerning native implementations is a trivial problem). Our integration broke in IE 11 because it depended onMapbeing polyfilled correctly.Diagnosing the problem with the IE 11 debugger over BrowserStack took a couple of days. It was a complex WebGL integration with a lot of dynamically loaded code running in an environment we didn’t control. Changing the load order was not an option. We were too far down the polyfill road on our end to replace core-js with ponyfills or some other, less deferential polyfill library without putting all our other client integrations at risk. The Magento contractor quoted an outrageous price to replace the broken polyfill on their end. That left the client with little choice but to give up on IE 11 support. The issue came up one or two more times with other Magento clients as well. That was probably the last nail in the coffin for IE 11 support at our shop. The first lesson I drew was that Magento used the wrong polyfill and was entirely to blame. After further reflection, the more valuable lesson I drew was that no one should have be using polyfills in the first place. Polyfills are an antipattern because they modify APIs they don’t own. I initially thought the ponyfill.com manifesto a bit puritanical, but having been burned a few times now, I’ll never use a polyfill in a new project again. We only ever used core-js in the first place because it shipped with Vue CLI’s scaffolding at the time. If I had to do the last few years over again, I would find a way to keep it out and use ponyfills instead.
Another problem with polyfills—one that Pushkarev wants to solve if he gets funding—is reducing the bloat they cause. One of his proposed solutions is akin to polyfill.io, where a browser gets served only the polyfills they need. But that’s an extra network round trip every browser has to make, and for features the code may not even be using. And for what benefit? To support a dead browser? To keep all browsers at the bleeding edge of the JavaScript API at all times? No, I think it’s time to simplify. I’ve stopped using JavaScript features that aren’t supported by the browsers we’re targeting. I’ve configured TypeScript and eslint in projects I work on to prevent anyone from accidentally using them. It just works.
You probably know this already, but it’s worth emphasizing that core-js does not polyfill
asyncnor any other syntax features. Those require Babel transforms. I’m not particularly keen on Babel in a post-IE 11 era, either. Babel-generated async code is difficult to debug and the more the code is transformed from its original, the less likely breakpoints are to line up with the source. This is very different from TypeScript’s erasable type system, which yields very accurate source maps, working breakpoints, and call stacks that more closely resemble the source.The hate mail people sent to Pushkarev was unwarranted as it was abusive. I don’t begrudge his advertisements in npm messages over the years. I don’t blame him for the war or his claimed neutrality. But I do feel weird about sending money to Russia right now. I wish the best possible future for him, but I don’t think it’s in core-js. Hopefully he can find a way to emigrate in spite of the accident, because it doesn’t seem like it’s in Russia, either.
[Comment removed by author]
Awful. Absolutely awful.
I wish the maintainer the best. I kinda hope they stop maintaining it and let it be. Let the corps do the work.
Given this difficult to read story, and author’s struggle in industry/skill combination, where should have been none – there are lessons here for the whole community.
My personal takeaway from this is, is that package hosting repositories (and the related package managers), are in the position today, to improve the compensation/support model for OSS developers.
Here are some ideas:
a) if a package needed funding is referenced directly, always display funding request, without additional commands (without npm fund)
b) if a package depends on package with a funding request, same as in ( a )
c) a funding request needs to have per-user request, per annual amount. This is to normalize the requests, does not preclude other methods of support. Is that just at least one of the methods of support should be clear and normalized
d) if there are multiple packages that, in effect, trigger (a) or (b) display one line noting number of packages, and the total normalized funding request.
e) If the is a package that requests funding, that depends on another package that requests funding – the should be an indicator that says a given package requests funding, and it relies on other packages that request funding. this is just to indicate that this condition exists
f) the funding goal had been reached for a year, there should be an indicator for package saying that the goal is reached, but the funding info as triggered by (a) or (b) should still be displayed (I am not sure how this is calculated, this can be done in different ways, so just including this for completeness).
h) If there is same maintainer for the same package in different programming languages, they should use the same funding request ID and other shared attributes, so that a contributor can see how their support works (or does not) across all the related packages.
g) There is probably a need to categories open source packages with funding requests as
1 - means that the package provides functionality that does not require presence of a commercial product
2 - means that the package provides functionality that requires presence of a commercial product
3 - is that it is not production ready, but is meant as a tutoring aid (eg books, or samples, or project starters/boilerplates)
–
Overall the above is aimed to create uniformity and particular ‘request marketing model’ that may serve a number of OSS developers better, especially if they are in a disadvantaged personal or economic or geopolitical situation
Oh, at first I think this would be abused easily, but perhaps not. The trouble is, who’s determining the funding goals? Whos’ the determining which package is “worth” more? I’d be happy to dump costs of doing all this on Microsoft, or whoever is hosting the code repo, I would say that they get more then enough through telemetry gathered, but it would be unfair both to them and to us - why should one commercial company be in charge of distributing funds?
I think most of the issues would be solvable. Good ideas, in any case.
thank you. I did not mean that gihub repo owner is involved.
I rather meant the NPMjs.com folks, and others that manage maven, php, perl, python (pypi.org) and such. Also they do not need to distribute funds (they could though). Instead, I think standardized funding method could be an appropriately sanitized link.
I was trying to ideate for a workflow that has normalized (uniform) representation funding requests in package ecosysytems where there deep dependency trees and only top-level dependencies (eg in package.json) are not easily surfaced for final solution developers.
In the case of core-js, it is rarely (in my limited experience) used directly as a dependency in package.json that developers at those commercial organizations mentioned in the article’s example are used, instead these kinds of packages are used inside by some other package (often serveral level deep).
It’s rubbish to have people treat you like shit when you ask them to pay for your stuff, but that kinda is open source. If you want to get paid you need to do a lot of marketing and/or license your stuff more restrictively.
I don’t think it’s very cool to be blaming the families of the people that you ran over for your financial troubles, tho.
Perhaps I’m wrong, but I didn’t get the feeling he was blaiming them for his troubles. It seemed to me more like explaining why he can’t leave Russia, because haters gonna hate, and dig that stuff out anyway, so he went upfront and explained. Like I said, I could be wrong though.
IMO add a bot to github so that every issue gets an autoresponse of “Sorry, until we meet our funding goals we aren’t providing support - ”
The problem with this is that it will invite abuse from entitled assholes like the core-js post is full of screenshots of. “Ridiculous, please turn this spambot off, I’m going to report this behavior to GitHub”
Fuck’em?
Oh for sure. But that may or may not actually work if your goal is better mental health.
Sorry but what exactly does “polyfill” mean? I have little experience with javascript.
JavaScript, like other Smalltalk-family languages, exposes pretty much everything to reflection. This means that there’s a very blurry line between the standard library and user code. User code can replace the global objects or methods on them that were provided by the standard library. You can effectively replace the entire standard library with your own implementation (modulo things that talk to the outside world, though you can replace these with wrappers).
A polyfill is named after the goo that you use to repair cracks in the walls (which tends to have different names in different locations even in the English-speaking world. Bill Bryson’s Notes from a Big Country discusses his problems trying to find the local name after moving back to the US). The problem is that you want to use modern JavaScript features, but you also want to deploy to all browsers. The solution comes in two parts. A polyfill for the standard library, which covers the cracks and makes whatever the browser ships act like a modern version, and a transpires that converts modern JavaScript (or some other language) constructs into things supported by all browsers.
My understanding is that a polyfill is effectively a compatibility layer for individual browser APIs, if the current browser supports an API used by the application then it’ll call into the browser runtime, otherwise it’ll use a reimplementation of that API from the polyfill of it.
Pretty spot on, with one additional use case: support for new, unreleased features. There are JavaScript features that developers like to use that are not finalized yet and not standardised, so polyfills, hmm, fill a dual role there. One, provide access to those features before they’re standardised and implemented by all browsers, as well as testing out these things before the standard gets finalized (so if a particular feature doesn’t really work out, it doesn’t get standardised and implemented that way).
[Comment removed by author]
I flagged this as unkind, but then I felt I had to comment and it would not allow me to without unflagging.
Who is this message for? Is it for the author?
This could have been you. Congratulations that you made different decisions that worked out for you.
There is no clear path to success writing and maintaining open source. Your own path is not at-all guaranteed for other projects, and in fact might be put at risk if every OSS project took it. If yours had failed for your project would you have welcomed feedback that compared it to other failures and ridiculed it as insanity to expect something different?
Your comment here comes across to me as dismissive, rude, and yes: unkind. It also refers to absolutely nothing about this specific situation and acknowledges nothing that the author wrote. It plays in to how people mistreat maintainers.