I wanted to share a great comment from this thread on Rails. But I think these lessons apply to any ecosystem.
These concepts are well-described and generalizable. If you are choosing a framework, or even building one, I suggest taking these four concepts into account.
Here are a few points regarding what makes an ecosystem healthy:
Maturity - Rails is a very old framework (first version almost 10 years old) and as such, is mature. It is possible for a software to be feature-complete and just release bug fixes. The "cons" of maturity are that newer developers will feel that the technology is boring because of wide-spread acceptance in enterprise and smaller shops.
Availability of libraries - It is difficult for a core framework/library to solve every single problem in a particular niche. As such, it needs a plethora of libraries(gems in case of Ruby) which depend on it and solve ancillary user needs. For example, in web development, a framework can provide routing, templates, caching but leave out ORM or DB access or authentication to other libraries. These libraries help a framework stay relevant. Rails has a plethora of gems which solve a wide variety of problems.
Assumptions - A framework or library is created with some core assumptions which are heavily based on problems of that time. Rails solved a very real problem of the time of quick prototyping and easy iterative development. As times change, the pressing problems of developers change as well. An existing framework may have to reinvent itself or risk being replaced by newer technologies which solve the problem better.
Inertia - A framework has to maintain a balancing act in terms of making changes. Breaking changes displease existing users while no changes lead to code smells due to old mistakes never being fixed. Add too many features and the learning curve and discoverability is affected.
Happy coding. ❤️
Top comments (4)
For me the most important metric is missing in this description:
The number one metric for me is documentation.
As a developer, I have seldom time. I need to get really fast an overview of what does the framework (in which way).
Therefore I need at first a lucid and easy to understand Getting started section. From there I skim the API documentation.
I could be in front of the next killer framework - if the docs suck, I go away.
I'm wondering, how important do you think is corporate backing for the health of a framework/library?
Use by a big corporate definitely helps as it has a snowball effect on adoption. OTOH, direct corporate backing can be a put-off for some for e.g if a framework is financed by a single corporate, outside devs may have second thoughts in contributing as their patches/features may not get accepted on the whims of the corporate. To get around this, most mature languages/frameworks have their own foundation which is in turn funded by companies. The type of OSS license used also plays a big part in this.
Thanks for sharing this :)