Its not necessarily bad as most new tools are slightly better than their predecessors, it just takes some getting use to and you have to learn how to structure your code base in a way that you do not have to completely refactor it every time a new build tool is adapted ;-)
If you don’t like a new tool, don’t use it. I can’t stand this kind of meritless complaints. If you’ve got a problem with the implementation of a new tool, that’s understandable. But to take issue with its existence? That’s just petty and a waste of everyone’s time.
If it takes away from their community and momentum, then yes.
Attention in FOSS is close to a zero-sum game.
Not to mention when the devs themselves get bored with tool X they've created and jump to creating some newer tool Y, dropping the whole community...
Given that you don’t pay for the product I don’t see anything wrong here. People work on what they want then change if they’re bored; you can’t do anything about that but pay them to continue supporting the tool you decided to use.
Things might not be wrong and still be a problem. E.g. your neighbor practicing tuba (badly) during the whole day, in perfectly legal hours...
In fact someone can gift stuff with the best intentions, and still cause a problem.
You can. You can encourage developers to contribute to a single project, rather than create fragmentation, which is exactly what's happening in this forum.
2) A fragmentation of development efforts across competing projects. Webpack has many contributors, but they'd have 1 more if the author of Parcel built parallelism into Webpack instead of a new bundler.
Second, even τηε premise of it being "unexpected" is not 100% true. None dev communities influence the development of projects all the times -- projects even have special voting boards for people to vote what features they want next etc.
Besides, it's very possible to not pay for a tool and still have a voice in the development of it. It just takes the development team to be willing to hear their userbase.
Last, but not least, direct payment is not the only/ultimate influence a user can exert on a project. Some FOSS projects are made by companies that want them to see wide adoption, so user complaints (of non coding users) matter very much -- things like Mongo for example.
In my experience, what is more common is that people who would otherwise not contribute to an existing project for whatever reasons (e.g. complexity, bad experience w/ maintainer, etc) start contributing to a new project because these younger projects are generally more approachable.
People don't really jump ship from something they've invested time into unless it's very clear that something else is taking over.
This was also the case with jQuery/Sizzle and friends back in the day. There's js-joda/moment/date-fns, underscore/lodash/ramda/just, css modules/styled-component/styletron, etc etc etc.
Lack of competition tends to lead to stagnation, and since js has such a large (and growing) community, you're never really going to be at a situation where major libraries will run out of community support due to competition of equal caliber.
Read Coverity's account of building static analysis tools for C: https://cacm.acm.org/magazines/2010/2/69354-a-few-billion-li...
"The C language does not exist; neither does Java, C++, and C#. While a language may exist as an abstract idea, and even have a pile of paper (a standard) purporting to define it, a standard is not a compiler."
The immense fragmentation of C compilers makes it difficult to build static analyzers.
You're correct that the cost of fragmentation is seldom that there's a lack of resources around any single project. It's more that complementary products are much harder to build, because there's no standard for the product category.
Change != !Improvement
So I'm not seeing the point here.
In my imperfect memory, it was perfect.. (I couldn't go back though...)