And there are people supporting their position.
I think because JS is such a large tent, there are folks not familiar with licenses and general norms in this space. I don't think it's something that being reasonable and pointing things out wouldn't fix.
As an aside I'm now extremely uncomfortable if I find any of ai's work as a transitive dependency for my company's own work because of their attitude towards adhering to licenses.
It's worth pointing out that this is all about a bunch of packages that decorate strings with ANSI colour escape sequences... I'm not saying it's worthless, or that there is nothing wrong in principle - but it's a lot of noise over something easily replicable from scratch - something simple enough that you may even choose to not bother with a library, (i've always just used ANSI codes directly in JS command line tools, sometimes defined in a few constants and interpolated for readability).
So perhaps the reason why one author is so pissed at misattribution, and the other allegedly doesn't seem to care much about it, is explained by a large difference in perceived value of the code.
To make my point more potent, imagine it was the same debacle over one of the many infamous one line NPM packages like "is-odd" which currently has half a million downloads per day and ultimately consists of the code "return (n % 2) === 1;"... excluding all of the fluff, and even with some unnecessary parenthesis.
But perhaps for contrast we should compare to the other end of the spectrum... Intel uses Minix3 in intelME which is part of every modern intel CPU . Minix3 has a 3 clause BSD license which requires reproducing the copyright notice for basic attribution . Which they failed to reproduce. Now in Tanenbaum's public letter, he politely suggested it would have been courteous if they had merely informed him of what it was being used for ... no mention of lack of attribution, no hysteria, no invoking of the mob on twitter, he didn't make even 1/10th the fuss this NPM package developer made.
Lets cut to the chase: The difference between these two people is that one cares about attribution way more than contributing to FOSS. They care about it to such a degree that makes me uncomfortable to touch their code, in-case of any perceived injustice against them or missed opportunity for self-promotion.
Attribution may not be a concern for career criminals but FOSS tries to stay on the side of the law. Otherwise, projects risk being "tainted" by copy-pasted code that could lead to even larger legal repercussions. ReactOS had its development shut down in 2006 because of mere allegations; they had to prove all their code was written by themselves
The way it was framed was that someone forked a packaged and started replacing all users; not what happened.
Also: I don't even use JS, so, I have no idea who these people or libraries are.
This is of course unlikely to be ai’s motivation. I just wanted to present a count point to the argument that such modules have low value.
I think this makes it easier to acquire an inflated sense of importance when an authors package reaches popularity - most of the small packages have some value and aren't as ridiculously worthless as "is-odd"; yet they also don't embody anything particularly unique or difficult to replicate.
> I wonder why there is not a simple math lib.
There are some non-standard but comprehensive math libraries such as MathJS. Although I don't think "is-odd" could be attributed to an absence of standard math libraries.
For every one thing, he broke it down into as many possible packages as possible, and all of his packages depend on 20 more of his packages. It's like a fractal of resume boosting.
My personal favourite is making every single ansi colour into a separate package, and then making `ansi-colors` which depends on all of them, and all of these packages are just a single function call with a provided number. It's honestly insane.
> Several years ago I switched careers from sales, marketing and consulting to learn how to program, with the goal of making the world a better place through code. Whether that means giving people access to information, the tools and technology to level the playing field with big corporations, or empowering people in impoverished regions to participate in the world economy.
> To date, I've created more than 1,000 open source projects in an effort to reach my goal.
They're good at marketing, I'll give 'em that.
"The way I learned how to program was by publishing one project a day that used a specific language feature I was trying to learn. No one even looked at my projects or used them until I had quite a few published. I didn't even want people to use them at that point, since I had no idea what I was doing. Then one day I realized that people were actually using some of the things I published as a learning exercise, and I started going back and fixing and improving that code. Rinse and repeat. That's pretty much all I did.
Why is the default for people to assume the worst all the time? It's depressing as hell."
If true, it's kind of sad so many people badmouth him.
What's actually harmful is the blind trust most developers have on adding dependencies without proper vetting. But if someone publishes a package they are not responsible for vetting it for inclusion in your project. So shifting blame to the library author gets responsibilities backwards.
Perhaps you would prefer a curated package registry, but in this case you would need actual curators. Something like Debian has maintainers, but doesn't have every library in existence (and what it has is often outdated anyway). Npm and other language registries aren't curated, by design. You could create a curated registry on top of npm but, again, you need curators.
Same argument as with spam. Sending an email is not a crime, and sending an email to somebody you didn't know to ask them maybe they want to do business with you is not that bad. Do it couple of millions of times, and it breaks the whole system.
> What's actually harmful is the blind trust most developers have on adding dependencies without proper vetting.
Now comes the victim blaming. Nope, the fact the people should verify stuff does not absolve the guilt of those who put garbage into the public space. On the contrary, they are making the problem so much worse. And yes, there are means to deal with the problem, but again "you can clean up" is not an argument that absolves the guilt of somebody who throws trash around. They are doing bad thing, and should feel bad about it.
> The color reset, in ansi. 
> The color strikethrough, in ansi. 
Which don't really make any sense.
This  might be what you are looking for, it has both is-number and is-odd.
I agree that the author clearly spent a lot of time polishing it, hence the pride and feeling of betrayal.
And now he's saying this of the person he took the work from :
1. "I believe he is a good person, but love colorette too much and prefer impulsive actions ... Impulsive behavior can be very dangerous."
2. "Comments like this [https://news.ycombinator.com/item?id=28662796] shows that his behavior in that case was very questionable. Seems like he is systematically put himself in conflicts."
True or not, I find his claims of the victim having impulsive or questionable behavior, and systematically creating conflicts, ironic.
On a more positive note - it looks like both parties are starting to discuss a resolution ; maybe even co-maintainership of the original work in question . I personally think that would take a lot of guts, from both parties, given everything that's transpired.
I also think johnnyshields in the linked GitHub thread  deserves acknowledgement for some noticeably simple, but effective, attempts at facilitating resolution.
Edit: Maybe HN is to blame as well.
There is something of a insane competition going on at various levels, people judging languages by their rank on various sources. Saying a specific language is "winning the race". We all know since the 70s that no language is winning ever. Calm down, code in what you like and people around you can use and understand. Create a new language, have fun... Things in life are not always a competition, you can relax.
Unfortunately this is what happens when any space gets super-competitive, then some people stop caring about spirits and anything else that's impossible to police in a meaningful way. JS is one of the, if not the, most popular programming language in use and it's incredibly accessible. It'd be (and I say this in the most polite and constructive way I could think of) silly to expect that stuff like this won't happen and that there won't be any group of people even cheering this kind of behavior.
We all seemingly live in bubbles, at some point we have to realize that we have the whole world in front of us in this crazy place called internet. Well, wasn't that the idea behind the "Eternal September"? It'll not get better unless the whole world gets better.
Honestly the best thing you can do is just not use Twitter or Github for social reasons. It's almost a sport at this rate. People trying their best to create drama and false gods. It's almost as bad as LinkedIn.
IMO, making fork, instead of integrating or writing their own(without the need to acknowledge original author due to significant changes to a code) shows struggle of dealing with this situation. I think that it is too harsh to declare it as intent that is directed specifically towards Jorge, but they took that route where they were vulnerable to attack. In the place of users of Jorges API(because I'm not related in any way to anyone here - I'm just reading this piece an making my comment), if I knew that Jorge would be taking this to public and rally a mob to torch other side, I would be making my own code, but then I don't exactl'y understand using so many unowned modules on personal project, as it is vulnerable to do so in first place(it saves some time initially, but if they are improving code so much, that it is running faster, then that is not an issue to write their own) - and one of the vulnerabilities is exactly this situation.
I am sympathising here with Jorge, but only on that side where his efforts in making that API might be significant to him. I don't see anything else good from this situation, as he is not going to get back his main user and others might avoid using his other works because of this conflict. Well, he might have a temporary victory in getting his name in fork, but that will just lead to ditching any code of his in future. The important part is distinguishing author side and his ability to communicate with users and once again I can sympathise with him as author, but not as user, as his communication and solving issues are taken from defensive-aggressive side.
You can like or dislike my opinion, but that does not change that fact.
I don't understand where this conclusion is coming from as it doesn't seem Andrey raised any concerns with colorette prior to his aggressive actions.
Well, okay, the forking could have been more politely, but author is a bit fast to pull the pirate card. It's a free/libre fork of a free/libre project after all.
> nanocolors implementation and API are the same as Colorette. You essentially pirated my work.
Copying and redistributing software without a license IS the definition of software piracy.
The current version appears to be MIT licensed. It is safe to assume that the fork was made under the same license. Given this assumption, and given that the MIT license requires copyright information to be preserved, stripping attribution is a license violation.
The claim of piracy is valid.
Fork has violated the license of original by stripping the attribution and history.
The problem with this behavior is as follows:
- The MIT license requires attribution of the original work. The author contacted the person who forked this privately . It wasn't done until the Twitter thread.
- Questionably the fork was renamed and didn't include git history to make the first point even worse. Git history was only rebased in after the Twitter thread .
1 - https://twitter.com/DerianAndre/status/1441851684095811585
2 - https://github.com/ai/nanocolors/commits/main?after=566a49b0...
Instead, danw1979 was asking for someone to explain why a reasonable comment was getting downvoted into oblivion. Neither danw1979 nor lmilcin did anything to deserve the random dogpile they received.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
We’re on the same page about them not deserving it.
Any source to this? Your referenced link does not support your hypothesis.
You can, indeed, see that they lack all of the original repo's commits.
The commits in nanocolor's git history also don't include Jorge's verified signature, which would come with the fork.
It's the Instagram-ification of the open source world. All of the feedback and social signaling mechanisms are there. Likes, stars, followers, and charts of "contributions". It's just an extension of LinkedIn for many people.
Let's not forget the DigitalOcean Hacktoberfest debacle a few years ago. I still stumble upon repos with pull requests that contain nothing more than a single character change to a README. Just for a stupid SWAG t-shirt.
The best way to avoid their insanity is to use JS as a target language, pick some of their good tools and move on with life, working with safer languages.
JS is a vast ecosystem with little barriers to entry, and
> Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
I don't think there's anything malicious going on, except a lot of people doing JS.
The dev who copied the code forked someone’s repo, went out of his way to remove attribution and git history, sent PRs to replace the original package in other libraries with his own version, and when called out on it got defensive instead of apologizing. I think malicious is a fair way to describe his behavior.
Would you mind sharing a link to such PR?
Even before this Twitter thread we had talk with Colorette author and I added mention to the docs, his name to LICENSE and promised him to not replace Colorette by Nano Colors.
The Colorette mention was there 5 days ago.
And was that before or after you opened several PRs to replace Colorette with Nano Colors?
He forked, stripped attribution and history [+] (license violation, but on its own probably just rises to the level of minor dickishness and is often a misunderstanding)
He started advertising his fork to replace the originally forked repo (a bit rude).
If the original library was unmaintained or unused, this probably would have been a big nothing-burger. But apparently the library that was quietly forked had a fairly big install base and contributing to that library first would have been a better choice.
What is missing from the discussion (and often unaccounted for in licenses themselves) is that there's a massive personal value to having a library used by large numbers of people.
[+] EDIT (to clarify): as gcr points out, this was not a standard github-style fork but rather a copy and re-commit as original history.
I have no experience with this - would you kindly explain that value? I am guessing that it has something to do with personal brand (my library is popular => I am good at this, hire me) - am I on the right track? Is there more?
It's terrible that clout is such a thing in open-source, but there are complex incentive issues that led to this point.
Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...
Your license should cover the history, in that every source file should bear a license header, going back to the first commit.
This is one way to do it. Problem remains when these important parts, even whole files - e.g. COPYRIGHT - are removed from the archived copy.
From what the original author reports, this is what happened.
When I've imported foreign files from other projects that don't have license headers, I give them license headers and also append their LICENSE or COPYRIGHT file into mine; I like belts and suspenders.
Removing history, itself, is not especially problematic. History is for maintenance, merges, and downstream compatibility issues.
I think it would be too restrictive. It might prevent you from working differently for no clear benefits. However, keeping the history is an easy way to track who contributed what so you probably should keep the history of projects with more than one contributors or you lose precise attribution in practice (apart for the other obvious reasons to keep the history).
Developing is in the burden of the single developer/project and which kind of version control system is used to produce releases can hardly be mandated by copyright law.
It is only one reason to use a F/L/OS/S license for contributing back, that is taking part in the development project. So on the other hand, it sort of does consider that, but it's merely then in the social interaction.
What so hurtfully happened here is that a collaborator tried to break the ties (forcefully) and was powerful enough to do so.
Sure, this renders the OSS license less effective, and I guess this can be seen or felt by many developers.
IIUC, IANAL, we don't have to worry about it.
Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed.
As far as I know, if you replace every instance of "version" in the previous paragraph with "commit", it still applies.
I think this means that every commit is under a specific license, and therefore, the entire history is under one or more licenses.
Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there.
And there is another sticky detail:
So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit).
This poses some problems on very public systems like Github as it may not be directly visible any longer.
One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping.
And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.
Licensing of version control history might need to have a legal debate, actually.
You can't do this with lax permissive licenses nor with copyleft as they allow to modify the work, which would mean the right to modify the history.
Is there any way to have an open source license that protects history?
If you want to remove the right to modify the project (which includes the history if shared as common on Github) it is not open source (free/libre) software any longer.
In this case such a license wouldn't be needed either honestly. There would be no win with it, b/c it would have been similarly easily violated and that's it. Don't hope for a strong "legal" thing here, it won't help to solve these kind of problems (IMHO).
And for the license troll:
Instead declare the repository on Github as Database Work. Put it under a proprietary license. Github _might_ falsely read a license from a software stored in that database as the database's license, but you can easily leave an "all rights reserved" in the project description that is more prominently visible than that.
> You should think this "wow, the author of one of the most popular frontend tools of today just used my work as reference. It's an honor."
By far my favorite and most ridiculous tweet I've seen in this thread.
It's marketed as if it was a standard, the fact that it isn't is tucked away in the readme, and also -- the entire project is just a wrapper around someones .eslintrc file, yet barely any credit is given to the ESLint devs who do all the work.
Go ahead and read the readme here, https://github.com/standard/standard. Could you genuinely tell this wasn't really a JS Standard at a glance? Could you tell this was just a config file for someone elses work? None of the donations go upstream to eslint by the way.
Hell, the actual config file is hidden inside a sub repo:
which has the audacity to claim
> This module is for advanced users. You probably want to use standard instead :)
It's a config file for someone elses program! Why does this library go through so much effort to hide that it's just someones config file? Why on earth is it called JS Standard Style?
The whole community is filled with slimy nonsense like this.
EDIT: also, this was the project that displayed ads in a million terminals on installs. It's 100% clear to me that this package is misleadingly marketed for personal gain.
But ESlint there does all the work, it's a self proclaimed "standard" that works very well in the modern working environments due to hype.
Colorette’s author created this thread because of my PR to Babel.
The US sort of half-heartedly added moral rights about 30 years ago in order to join Berne, but they are limited mostly to works of visual arts and would not apply to code.
They are not so limited in most of the rest of the world. Furthermore in much of the world (such as most of Europe) an author cannot waive or assign their moral rights and so any license term that purports to do so would be invalid in those places.
Even if I was the kind of person who would want to misattribute someone else's work as my own, unless I was very very sure that I only had to worry about US copyright law I would tread very carefully.
Something tells me they wouldn’t be so calm about the whole affair
Gorge Bucaran, author of Colorette, summarizes your actions here https://github.com/ai/nanocolors/pull/14#issuecomment-927134...:
"Colorette isn't some obscure project either. It is well used. Now imagine I find a project that meets that description. Clone it. Erase the .git directory. Initialize a new repository. Make a few extraneous changes. Incorrectly benchmark it. Falsely claim improved performance. Tweak the docs. Change the name. Add a logo. Start aggressively promoting it and sending PRs to high-profile projects while leveraging a non-trivial social media following. I'm not against forking a project and adding new value to it. I encourage that. But that's not what's going on here. This is the collector getting away with a new piece for their collection."
Comparing that, to "promoting alternatives" to one of your projects on Twitter, shows a creepy lack of acknowledgement.
But that's why we're here, isn't it?
Just look at performance changes history,
Nano Colors mentioned Colorette in docs, COPYRIGHT and keep origin git history.
If Nano Colors was open about credits, why Colorette’s author should not do the same?
EDIT: lol, I only now realized you are ai. So now you are here, pretending you did all this the entire time and did not only add it all back after being called out on misrepresenting it? And at the same time trying to point at the other guys mistakes?
Just after Colorette’s author asked me. We even agreed on text form of this mention.
He started Twitter thread because of my PRs to Babel.
After Twitter thread I just copied git commits (only because another person helped my with doing it right) and created COPYRIGHT file (but Colorette author was mentioned in LICENSE before the threat anyway).
Fork button will not work for this case.
According to the original project's author, he even silently removed loads of edge case handlers until he was called out on it . That seems to have been a really quick and dirty tactic to get his performance numbers up.
My spidey senses are tingling too.
Desperate people do desperate things and this surely looks desperate.
For what it's worth, these dealings left me with a very solid impression of his person, one that his current behaviour does not at all match.
It is either just a really bad judgement call and an even worse handling of the resulting fallout, or, if something fishy is indeed going on, the result of some external source of pressure (blackmail, money problems, compromised account, ect.).
The issue only being resolved  when public shame was involved should close this case.
1 - https://github.com/ai/nanocolors/blob/main/COPYRIGHT#L1-L3
It's not always bad, but it stifles creativity and I believe has caused us to be stuck with libraries just because "they are popular and well-maintained" versus finding the actual ideal solution, the React ecosystem being a strong example of that. Not to mention that, contrary to what you would expect, the larger the company, the more often decisions will be made based on github star count, almost completely ignoring technical merit.
I spend virtually my entire workday in a terminal, and I’ve never once needed a CLI tool written in JS. Where is all this code going?
In Python, the experience has been the opposite. We had to wait until recently to have once very good decent terminal coloring lib: rich.
Very interesting mix of JS+CLI indeed
It's even easier on UNIX-like terminals, where ANSI escape codes should work.
Would totally believe that lowdash is a lodash fork.
As for where it’s going, Node based CLI programs. For example, `yarn upgrade-interactive` uses it (a chalk-like module)
* From bootcamps without any other serious knowledge.
* A culture of resume padding
* A total lack of care about security, performance or reliability.
Even the context is absurd: we’re on a website that calls itself “Hacker News” but caters chiefly to the relatively narrow and un-hacker-like interests of a handful of overcapitalized investors.
Perhaps "hax0r" would be more appropriate.
> It will have a good support. My other projects from nano-series like very popular Nano ID shows a minimal number of bugs and excellent response time.
Should we copy your code, attribute it to you in a readme, and slightly optimize some of your code to replace your efforts everywhere?
When people later explained how to keep the history of single file I tried to restored it.
Many packages attempt to be those “as seen on Tv” gadgets which fix weirdly specific issues in a functionally-fixed way. Single-function goods are frequently given cutesy branding names in hopes of making their way into your home/package.json. Now we even have the product-level copycats.
Computer code is not an appliance, and no one cares how many people play with your little gadget.
Node.js ecosystem makes things worse because of package number inflation due to a piss poor standard library (praise DENO).
I’m admittedly pretty ignorant to software licenses but I’d imagine they can help in at least this scenario.
but it does conflict with this particular remark:
"the original author has no rights to draw consequences from this rip-off"
since the license requires attribution, this is false.
I clearly explain the reasons of fork creation and the changes https://github.com/ai/nanocolors/wiki/Colorette-Changes
What “fork rules” did I violate?
You could poison most of the web dev ecosystem by changing the license on a handful of packages to GPL...
The author's comments are quite enlightening of their incomplete understanding of the licenses they use:
> nanocolors implementation and API are the same as
> Colorette. You essentially pirated my work.
After using a license that explicitly allows others to take their work, it's suprising the author thinks that someone "pirated" their work.
Hopefully this signals the start of an awakening within the JS ecosystem, with more and more developers switching to licenses like the GPL that actually respect the developers.
He stripped the license when he created his fork. (Only adding it after the thread on Twitter became actively noticed).
How is that _not_ pirating?
If you use a gpl licensed library in your project, it essentially becomes gpl licensed too. If you ever want to sell your software, this is probably a big no-no. It will become quite challenging, and could end up in a legal desaster.
So to create a successful library, other people are willing to use, you essentially have to release it without restrictions.
IIRC, the MIT license does not require attribution (EDIT: it does)
Most people do not understand the philosophy of Open Source. It's not "hey look at me, I made this, look at me".
They should not give liberties to other people if they don't want them to use it.
EDIT: Seeing the comments to this one, this should be seen as a proof of Cunningham's Law
 - https://meta.wikimedia.org/wiki/Cunningham%27s_Law
The MIT License (MIT)
Copyright © 2021 <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
He was violating the license until 19 hours ago: https://github.com/ai/nanocolors/commit/1d86f02ca751ad8c113c...
The MIT license is a bad license but in this case the terms of it were clearly being violated by a hostile actor.
I did not claim I was "sure", which is the point of "IIRC". Calling this misinformation is a bit exaggerated.
You can choose to be kind.
IIRC isn't necessary when the content is clearly and easily accessible for you to read, I would prefer to not have to read comments based on vague memory when the facts are right there. This is netiquette.
They're also not saying that they weren't allowed to fork it. Just that it was an asshole move, and in community efforts that matters too. The exact same thing could happen with a GPL project, no difference license-wise.
"The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software."
It clearly requires attribution.
What am I missing?
A lot of drama can often be avoided if people just communicate better.
This doesn’t feel like a communication issue as much as an ethical question.
It couldn't have been. Forking 'properly' on GitHub is a single click. Doing what they did required cloning, erasing .git, then creating a new repo. The original history (now replaced with colorette's) even had an 'initial commit' by ai.
This was 100% malicious.
Wahoo, a framework I had built, became the base for the then, new Oh My Fish.
I, myself, committed it into the Oh My Fish repository, effectively replacing everything but the name. This was a huge change.
Regrettably, I didn't include a migration strategy, and ended up breaking other things down the line because of that. This and poor communication on my part, eventually led to a fallout with the other maintainer and I exited the project. So, I asked them to revert my changes or provide full attribution.
Reverting my changes would've made no sense at that point, and I realize that.
Attribution was left as "Copyright (c) 2015, Oh My Fish!". That didn't do it for me. My name was not anywhere. Ironically, my name is now almost everywhere Oh My Fish is brought up.
Filling a DMCA notice was my careless reaction to the situation. I know that I could've handled it better. I wasn't at my best.
1. You contributed code to the project that broke a lot of stuff
2. You tried to "take back" the contribution - this is really rich, as you already gave the code away as is without attribution according to the repo license.
3. Your ego just couldn't accept not being mentioned, so you thought attempting to kill OMF was a good idea. Your fame and glory was important enough to try to kill a popular open source project.
It's not that you could have handled it better, you behaved with ego and toxicity every step of the way.
1. From a technical standpoint, it just meant swapping Oh My Fish for Wahoo and changing the name. But my complete lack of planning led to numerous issues that escalated to falling out with the team. I was new to FOSS, immature and reckless.
2. Absolutely. You can't take back gifts that you gave away in the first place. I could've looked for another way, but sadly, I didn't.
3. True. I felt slighted, and used that feeling to justify myself, but in hindsight, I was only being selfish.
Chalk maintainers basically discard the performance improvement as micro-benchmarking (i.e. "doesn't matter in the real world"). Chalk maintainers also say tree shaking doesn't matter in the real world.
Why do they minimize these 2 improvements? If 2 libraries are equivalent, I'd go with the ones with extra improvements.
Chalk maintainers also mentioned that chalk would have no dependencies soon (not now, but soon). They also mentioned that chalk is well maintained for over 10y.
So, over the past decade, they can't remove dependencies? Suddenly, nanocolors show up, and now they will remove dependencies soon? That doesn't sound well-maintained.
Speed/tree-shaking aside, having no dependencies is a huge improvement.
Chalk’s purpose is to color things printed to the terminal. Unless it’s performance is atrocious, which I doubt, it doesn’t matter unless a ridiculous amount of data is printed.
> Chalk maintainers also say tree shaking doesn't matter in the real world
No, they say it doesn’t matter for chalk’s use case. Which is command-line tools that are almost never tree-shaken.
Chalk is downloaded 15 millions per day.
We probably can multiply how much time has wasted from 15 millions run per day. It matters collectively.
> No, they say it doesn’t matter for chalk’s use case. Which is command-line tools that are almost never tree-shaken.
Are you saying people don't package the terminal app when written in Node.js?
It matters in some cases, and it doesn't matter in some.
Chalk maintainers try to brush off these improvements, which seem like bad intents, tbh.
> Chalk is downloaded 15 millions per day.
> We probably can multiply how much time has wasted from 15 millions run per day. It matters collectively.
If I give you back 5 seconds each day, will it matter to you? Will you be able to enjoy or do something that you otherwise wouldn't? I doubt it. I am certain that is true practically every person in those 15 millions.
The cumulative loss of something can be huge, but still don't matter because its distributed to a degree where it is barely a rounding error.
> Are you saying people don't package the terminal app when written in Node.js?
Details matter. Chalk is ~100K and nanocolors is 16K. Yes, 90K is meaningless saving for a terminal app.
Are you claiming it doesn't matter to anyone or just you?
> If I give you back 5 seconds each day, will it matter to you? Will you be able to enjoy or do something that you otherwise wouldn't?
I'd welcome the time back since I don't lose anything in return anyway.
So, a big YES here.
Generally I would put faster library as a plus.
Working in a big company, when choosing between 2 open sources, we will need to list down pros and cons.
Among other things, being 4x smaller is definitely one of the plus consideration. I try not to exaggerate this; it's not a major plus, but a plus nonetheless
Saying these doesn't matter is disingenuous.
To you, maybe, but not for most. If everything else is equal, you would choose chalk despite it is 4x bigger in size and slower? Most will choose the smaller and faster library.
As a web developer I generally prefer things being faster and/or smaller too, but I would not change a working field-tested library for negligible effect. The problem in the case that is being discussed is not which library would be chosen when none is being used yet, but does it make sense to replace an existing one to save 90K of disk space and maybe a few seconds per day? To me this looks like very definition of bike-shedding and yes, I would definitely not switch library if these are the only compelling reasons.
4x smaller than the other one doesn't really tell anything without considering how big the whole app that uses this library is. On our fairly basic Nuxt project node_modules directory takes 250M. Do you really think any of us should care about 90K?
And lastly, you don't know me. Save your "disingenuous" remarks for people you do.
The benchmark measurements they're discussing are on the order of tens-of-millions of operations per second: https://github.com/ai/nanocolors#benchmarks
Are the contents of your terminal changing that frequently?
- contributed to the original project for a year
- forked the original project only after the author did not agree with the his requests/prs
- (turned out this was done latter after it became publicized) kept the commit history as well as attributing the author in the docs
- All in accordance to license (MIT)
- modified/improved on the original project in his fork.
It looks like he performed the fork after the original author moved the project in an undesirable direction. I mean what else would could he have done?
Isn’t the awesome part about open source that if someone changes their lib underneath you, in a way that you do not like, you _can_ fork it and keep it in the direction you desire. And after that “the market” decides which direction was more to the users liking?
I’ve been ripped off by others as well and know the feeling of betrayal when you see someone getting praise for work they have not done, but this seems hardly the case here.
He didn't. He added that after being publicly called out on it.
People should be encouraged to open source their code if it's useful for the community. They should not be worried that some big gun take it and promote it as its own.
I wonder how the community can best prevent this behaviour?
This is why I used Colorette for a year, promote it and send PRs there.
For for created because Colorette changed API and author didn’t want to change it back. The reasons of fork is clearly desrcibed in project’s docs
I mentioned Colorette in Nano Colors docs, COPYRIGHT and keep the origin history.
But when Colorette author backported my performance optimizations he refuses to do the same in return.
You did not mention colorette until you were forced to do it. Why not talk to the author before making a fork?
You mention that you disagreed with changes in colorette, but you have no evidence for it. If you discussed it in an issue or PR, that would be easy to find and share.
You took all of colorette.
The "backported" performance improvement is a single line of code. That you try to make it seem like exactly the same thing seems childish and bullish to me.
If you are really not acting in bad faith, why not drop your fork now that colorette has changed the API back?
First mention (it was changed later) was added 6 days ago (threat was created 2 days ago):
Webpack team ask Colorette’s author to rollback API 2.x changes here (discussion was cleaned by Colorette’s author, but he said that it is how it see the best API):
> why not drop your fork now that colorette has changed the API back?
Author continued to act impulsively. He rolled back API in patch release instead of major made breaking changes.
The author acted impulsively after you copied and rebranded his package and then started pushing it everywhere. And now that's your excuse to keep your fork.
To get back to my original post. We want people to open source their code if it's useful for the community. Your behaviour here is going to scare people away from doing that. One little mistake and then boom someone with a bigger name takes all of your work and fame.
Don't you see that this is not beneficial for the community?
The colorette's creator, Jorge, tried to dcma other repos on GitHub: https://news.ycombinator.com/item?id=10271304
Use his libraries at your own risk.
"@jorgebucaran sorry for PostCSS/Browserslist migration from colorette. I understand your feeling (but it was an only move in case of colorette 2.x API changes and following API breaking change in patch release).
If you want to send another PR and replace chalk to colorette, I am OK with it. Babel’s users will be happy in both scenarios, since all colorette and nanocolors are both much smaller than chalk.
rebranded it as nanocolors
It is not true. Nano Colors was influenced by colorette API and internal design and I mentioned it in top section of Nano Colors docs. However, it is not rebranding:
I mix ideas not only from colorette but also from kleur, another great color formatting library.
colorette and nanocolors has very different results in benchmark showing difference in internal implementation.
If you compare kleur, nanocolors, and colorette you will see many similarities (because it is open source, and they share ideas between each other), but also many differences:
In color detection. Nano Colors uses process.argv to be compatible with Chalk.
In color’s functions. Nano Colors do not generate RegExp on every call for performance reasons. It also doesn’t have init/raw separation.
This is not in the true spirit of open source.
Forks and idea sharing are also an important part of open-source if they are coming with respect to authors of origin ideas and mentioning them.
You are mentioned not only in docs (colorette mentioning text in Nano Colors docs was even approved by you) but also in LICENSE.
Before colorette 2.x API changes, I promote your project to other projects because I tried to find chalk alternative. I sent you PRs. I used your library in all my projects for a year.
We all stand on the shoulders of giants. We both used Chalk color detection algorithm as reference. We both using other source code to find the best optimizations.
If you do not like that your tools is also used as an inspiration (with mentioning you), feel free to replace this PR with PR of replacing chalk to colorette."