## Package-Rot as growth hindrance Hello! I am new to the community, but I am already in love with the language.
One Problem that I have encountered is that there is "package-rot". Since nim is a small(adoption wise) language, lots of projects are by a single author and at some point this author will stop updating the project. A Project that is not updated for one year frightens me - maybe unjustified, but I am sure lots of people will go to Awesome Nim -> nimgame2, and find it abandoned "2 years ago", then they are like: Is nim dead? **The strong-point of nim is nim itself** , but the weak point is (at least from the newbie perspective) the package situation (rot, not merely existence). Btw. I have found plenty of tutorials, so the Tutorial-Situation is fine. So I have basically a few ideas: ## Getting Information What about adding a feature to nimble (or small tool on top), that reads the git repos from the package repo and lists how old they are. Then add tags for categories and create a visual (f.e. html) output that shows how the package situation in each domain really is. This would allow a non biased, data driven view on the whole situation. ## Creating a Squad Sure there are enthusiastic nim-warriors; they could form a "package-squad" or "battery-squad" \- and specifically organize the resource of nim coding time to the important breaches within the package-situation. The squad can then create a website with most important contributions and packages to update - or to create in the first place. So there is a place to add to nim, without working yourself into the compiler, which most people don't like - since most people are not compiler devs (like myself - mostly web and simulation). ## Package Culture Revolution It would then help, if the package squad defines a "Battery-Squad-Package-Quality"\- Standard, which is mostly documentation for __newbies__ (like me). I don't know all features, so if the documentation of the squad packages is very good and also explains more obscure language concepts where they are used - this would greatly increase the simplicity of reviving projects if the core maintainer goes away. Another Idea would be not only including _some_ examples, but lots of GREAT Examples, with documentation of some language patterns that are used - basically **proto-Applications**. So a focus on Examples for newbie-users. A positive side effect would be that the usage of a "Squad-Package" would so advertise the great features of nim, which do not shine in a 20 lines example. ## Goal Over time this would build a number of packages, that are well documented and maintained, and would greatly increase the rise of nim (at least in my head this makes sense) - and the love and join for programming in the world. > Is there something like this already and I am to stupid to find it? > > Is there a flaw in this logic? Do I miss some important aspects? > > What do you think? Personally I would volunteer as a member of the "battery-squad" if this discussion suggests that this whole thing might be a good idea.
