Everything collapses
Let's try together to reduce fragmentation in the JavaScript world. Recently, after the announcement of Yarn , some in the JavaScript community criticized Facebook and the project as a whole.
There is a tendency for companies or individuals to fork or re-create OSS projects, instead of working on existing ones in the community. This happens for many reasons, but it happens more often than necessary. This explains why Yarn appeared.
Essentially, there is nothing wrong with DIY in OSS. For developers, this is a good way to learn or show what you are capable of. As long as you don't have a fan club, it's a drop in the ocean.
But if it makes a business that can allocate resources and talents for the project, with the right connections and marketing - this is akin to a cannonball. And acts solely in their own interests, which can harm the OSS community.
')
I want to tell why the company can come to this decision (see also: a fatal flaw ), and what the consequences may be from this.
If it happens that an OSS project X may work for a company in some scenarios, it will try to use it.
But it is possible that she has not studied it well enough, or her needs have changed, or the sphere has changed, or bug X still fails or a million reasons. Instead of cooperation, the company takes and writes its implementation.
The developers in the company understand that it will be cheaper to do everything themselves. I know this because I did it myself. And this makes some sense.
Business loves and agrees with the idea that it “can return” to the community by opening the sources of its new project! Developers in the company also like this because they write code by their standards and practices. They are no longer dependent on the whims and time frames of anyone else.
A more attentive business will make a more conscientious decision and return the input to project X. While the code is merging at a reasonable time, everyone is happy. But if the PR is hanging too long or the maintainers do not agree with the decision and rejected the request, the cooperation may end.
What will result in a new project Z, which will lead to fragmentation on several levels:
Individuals, business, and project maintainers could try to prevent potential fragmentation. Maintainers are too tied or often do not understand what users really need, or they have a different motivation. Companies think that they encounter “unique problems” more often than they really are.
From the above, I would like to focus on the fragmentation of the ecosystem, as this is related to the recent announcement of Yarn.
When I tried to use alternatives to npm cli, my packages just broke down. They broke down because they expected to be installed via npm cli. Not too obvious, but it's all about lifecycle scripts and how cli handles the symlinks of directories in a special way.
I suspect that there are many such packages, and you use at least one.
Do not expect the npm cli alternatives to provide 100% compatibility with the current ecosystem. If they did everything the same as npm cli, everyone would stop using npm cli, including npm cli itself.
Even if the cli alternative provides greater security and performance, widespread adoption will cause some level of fragmentation of the ecosystem.
Newcomers to the node.js and JS community are faced with another choice of which tool to use. It will not be clear to them why npm does not work with this library, which was written using the alternative cli. Or why alternative cli does not work with this library, waiting for npm.
Despite all the efforts and attention invested in Yarn, he will not be able to cover all cases, not everyone will expect 100% compatibility. Veteran JavaScript ecosystem will be able to find workarounds, but novice no.
You are the project maintainer. Once you receive an error message from the user:
Forget that you spent last week fixing Windows support. Now you need to worry about quuxbaz support on Windows.
You can see how fast this problem is growing. If you already support three (3) versions of node.js on Linux, Windows, and MacOS (9), then your matrix doubles to eighteen (18), considering that quuxbaz works on these nine configurations. But it may not work, so forget about those strange bugs you have been working on, this is actually a problem with node.js 4.x under MacOS using quuxbaz.
I don’t expect this, but I don’t want an overhead projector anymore, it’s not that I want to immediately take and give up quuxbaz support. And I apologize to you in advance if I write this question in the tracker of your project.
A more specific example: when Browserify appeared, many packages on node.js magically started working in the browser. The rest were broken. Some have fixed this "bug", others do not. Time passed and now Browserify works like normal, but not with Webpack. And then it breaks down in some kind of browser, or electron, or a phone or a toaster, and so on.
How do we avoid such problems?
Despite the reasons why we are here, we are all together.
As a consumer of Node.js modules, you can help the project maintainer by sending more detailed bug reports and / or code that fixes these bugs. If you post a bug, watch for its correction. If you are using a code, please help support it. The last part, especially important.
As a maintainer, be open to new ideas and perspectives. If you put something on Github, you should expect someone to use it, not the way you assume it. You will be surprised how many disagreements decide to “leave it behind the flag ”.
For business - and specifically for R & D teams - if the project has an active community, join. It may be that another user wants the same feature as you. Maybe you can work on it together, like the Yarn team.
You guys have made incredible efforts. Probably there is some kind of misunderstanding around the existence of the project.
Please help understand the community, and especially newcomers:
If tomorrow I see a new search for "does not work with Yarn", although I do not expect what I see, I would like a wiki or documentation describing common problems, solutions and known incompatibilities, frequent user errors and so on.
And if it's not difficult for you, please keep 100% compatibility with npm for the flag, thanks.
There is a tendency for companies or individuals to fork or re-create OSS projects, instead of working on existing ones in the community. This happens for many reasons, but it happens more often than necessary. This explains why Yarn appeared.
Punks not dead!
Essentially, there is nothing wrong with DIY in OSS. For developers, this is a good way to learn or show what you are capable of. As long as you don't have a fan club, it's a drop in the ocean.
But if it makes a business that can allocate resources and talents for the project, with the right connections and marketing - this is akin to a cannonball. And acts solely in their own interests, which can harm the OSS community.
')
I want to tell why the company can come to this decision (see also: a fatal flaw ), and what the consequences may be from this.
With good intentions paved ...
If it happens that an OSS project X may work for a company in some scenarios, it will try to use it.
But it is possible that she has not studied it well enough, or her needs have changed, or the sphere has changed, or bug X still fails or a million reasons. Instead of cooperation, the company takes and writes its implementation.
The developers in the company understand that it will be cheaper to do everything themselves. I know this because I did it myself. And this makes some sense.
Business loves and agrees with the idea that it “can return” to the community by opening the sources of its new project! Developers in the company also like this because they write code by their standards and practices. They are no longer dependent on the whims and time frames of anyone else.
A more attentive business will make a more conscientious decision and return the input to project X. While the code is merging at a reasonable time, everyone is happy. But if the PR is hanging too long or the maintainers do not agree with the decision and rejected the request, the cooperation may end.
What will result in a new project Z, which will lead to fragmentation on several levels:
- Community Because of the separation, some users may switch over to Z. Maybe Z suits them better, or they believe that Z will develop faster, or because it is new and shiny. Contribution to X may decrease.
- Effort . Users will now be contributing to Z instead of contributing to project X. Parity on features or compatibility duplicates efforts.
- Ecosystem . Project X is well distributed and it has plugins, and it provides integration with other tools. These tools in ecosystem X may or may not be compatible with Z.
Individuals, business, and project maintainers could try to prevent potential fragmentation. Maintainers are too tied or often do not understand what users really need, or they have a different motivation. Companies think that they encounter “unique problems” more often than they really are.
From the above, I would like to focus on the fragmentation of the ecosystem, as this is related to the recent announcement of Yarn.
Same but different
When I tried to use alternatives to npm cli, my packages just broke down. They broke down because they expected to be installed via npm cli. Not too obvious, but it's all about lifecycle scripts and how cli handles the symlinks of directories in a special way.
I suspect that there are many such packages, and you use at least one.
Do not expect the npm cli alternatives to provide 100% compatibility with the current ecosystem. If they did everything the same as npm cli, everyone would stop using npm cli, including npm cli itself.
Even if the cli alternative provides greater security and performance, widespread adoption will cause some level of fragmentation of the ecosystem.
Not easy to be green
Newcomers to the node.js and JS community are faced with another choice of which tool to use. It will not be clear to them why npm does not work with this library, which was written using the alternative cli. Or why alternative cli does not work with this library, waiting for npm.
Despite all the efforts and attention invested in Yarn, he will not be able to cover all cases, not everyone will expect 100% compatibility. Veteran JavaScript ecosystem will be able to find workarounds, but novice no.
Multiply the build matrix
You are the project maintainer. Once you receive an error message from the user:
hey, this package does not work with quuxbaz, new npm client, add support pliz.
Forget that you spent last week fixing Windows support. Now you need to worry about quuxbaz support on Windows.
You can see how fast this problem is growing. If you already support three (3) versions of node.js on Linux, Windows, and MacOS (9), then your matrix doubles to eighteen (18), considering that quuxbaz works on these nine configurations. But it may not work, so forget about those strange bugs you have been working on, this is actually a problem with node.js 4.x under MacOS using quuxbaz.
I don’t expect this, but I don’t want an overhead projector anymore, it’s not that I want to immediately take and give up quuxbaz support. And I apologize to you in advance if I write this question in the tracker of your project.
A more specific example: when Browserify appeared, many packages on node.js magically started working in the browser. The rest were broken. Some have fixed this "bug", others do not. Time passed and now Browserify works like normal, but not with Webpack. And then it breaks down in some kind of browser, or electron, or a phone or a toaster, and so on.
How do we avoid such problems?
Teamwork!
Despite the reasons why we are here, we are all together.
For users
As a consumer of Node.js modules, you can help the project maintainer by sending more detailed bug reports and / or code that fixes these bugs. If you post a bug, watch for its correction. If you are using a code, please help support it. The last part, especially important.
Maintainers
As a maintainer, be open to new ideas and perspectives. If you put something on Github, you should expect someone to use it, not the way you assume it. You will be surprised how many disagreements decide to “leave it behind the flag ”.
Business
For business - and specifically for R & D teams - if the project has an active community, join. It may be that another user wants the same feature as you. Maybe you can work on it together, like the Yarn team.
Team yarn
You guys have made incredible efforts. Probably there is some kind of misunderstanding around the existence of the project.
Please help understand the community, and especially newcomers:
- What is Yarn and what is it for?
- Why precisely he?
- What can you expect from working with him?
If tomorrow I see a new search for "does not work with Yarn", although I do not expect what I see, I would like a wiki or documentation describing common problems, solutions and known incompatibilities, frequent user errors and so on.
And if it's not difficult for you, please keep 100% compatibility with npm for the flag, thanks.
Source: https://habr.com/ru/post/312762/
All Articles