You wouldn't think a free syntax highlighting library would be a strong dependency for the development process of a business, and yet I'm waking up on a Monday to a flurry of comments and even one personal email from engineers eager to ask me to work for free for their employers.
So of course I took time to scathingly turn it into a teachable moment.
https://github.com/highlightjs/highlight.js/issues/1984#issuecomment-466941892:
I would like if you revert the change. It is currently blocking a lot of build from other people
Let me take this as an opportunity to explain something about the current sorry state of relationship between businesses and open source projects. (Yeah, I know, but people still don't get it.)
highlight.js is not a business, it's a hobby.
It means that whatever gets pushed to this repository or npm should be assumed to be the result of someone having fooled around and gone away for a weekend with their family. Or for a busy working day at their job.
If a business has made a decision to rely on this artifact for anything requiring any sort of stability (i.e. "blocking a lot of build from other people"), it made a stupid and uninformed decision. Or more realistically, it simply relies on maintainers feeling ashamed enough to quickly fix problems when they happen. Even more realistically, it just accepts the fact that their engineers are going to deal with maintainers by soliciting free support, because it has always worked this way. I, for one, don't feel any urge at all supporting someone's misplaced expectations :-)
So, dear fellow engineers, please take this build hiccup as an opportunity to explain to your particular business people that their entire intellectual property is a thin layer on top of a shaky foundation of open-source code lazily maintained by hobbyists or paid for by other businesses having their own goals in mind. Mention the leftpad story for more effect.
If they really want stability they have to invest in it.
… by, for example, hiring engineers to deal with myriad of dependencies, maintain local stable forks, contribute patches upstream, or whatever — the key point is that it should not look like it "just works" on fairy dust.
Comments: 6
Haha, well handled.
I'm dealing with a situation at present where someone seems to think that my providing something for free means I have to adapt it to suit their needs.
And then there's the people who post using ALL-CAPS as if shouting at me will make me want to help them.
And most unfortunately, we can't challenge them directly because then they act all hurt and make out somehow we're all to blame.
Or by at least by vendoring the dependencies and being able to restore version that worked for them :)
So, the one and only real reason for choosing open-source solutions is as follows: ~~if~~ when things go bad, you can fork it. And if you do not have the required resources for maintaining your own fork - you are screwed.
@Shura you don't even have to maintain your own fork. Just don't upgrade your dependencies without some sort of change control. I seriously doubt people who can't maintain a fork really need the latest bits versus just suffering from turn-it-up-to-11-ism.
This is only an issue if you're indiscriminately running off the latest bits and want to complain when a change doesn't work well for you. Well yeah, you throw knives at your friend's head you'll miss 99 times out of a hundred but that 100th time...
I wish people would use FOSS or FLOSS for the acronym — mostly because every time I read "OSS", I have to figure out whether the author means Open Source Software, Open Sound System, or something else (Office of Strategic Services, e.g.)
Sorry.
The biggest problem for me in maintaining code is that old, perfectly working versions of open source software disappear and fall off the internet. The code for my book breaks constantly when old artifacts disappear, though people do push fixes because it is open source.