I had an idea some days ago and might be in line with the lets say marketing strategy of meteor.
Why not create a meteor-community github organization and rebrand some of the most important packages that have been abandoned and or their mainteiners agree to change the ownership.
I think this could have a possitive effect having a more up to date and better maintained repos that can make improve the confidence for newcomers.
What do you guys think about it?
Well, the old system without imports still works. But having everything available globally easily becomes unmanageable as your application grows. And more important, it makes Meteor in line with the javascript ecosystem. Meteor started out with its own packaging, module system, code-style, etc⌠While many of these decisions were well motivated and often way ahead of their time, they made Meteor stand alone on an island. And as the JS ecosystem evolves it became hard to keep up and developers left Meteor.
I have my concerns about this because youâre basically giving plugins then on the hand of many where not everyone is cooperating with everyone else. You can easily have people who âjust want to fix something smallâ and start pushing out a new version as they please etc.
Maybe itâs a part of my german culture, but I like if someone is responsible for things. This is also why (in my eyes) packages should have maintainers and not just be âat the communityâ.
Iâd rather personally pick up packages which have been abandoned and ask the author to get access to github and atmosphere to publish new versions on their behalf - or join groups having packages which are related to each other (like the meteor-testing group).
Iâve also started forking packages and pushed out a notification in this forum about it and in the ticket system in case the author was not responding to my request (either approving or denying - but just keeping silent) for weeks or sometimes even months.
I know I will lose the battle in advance because you all chose the âcommunity aspectâ first and my opinion is unpopular.
I will share it still. Maybe some people will stop being dogmatic and actually listen 
I argue that there should be the choice: all fine for current imports system. Letâs keep it.
The concept of automatic imports should be pushed further.
This is so handy for small teams, and for prototyping ! Which is where Meteor (used to?) shine
The automatic import system is still working, but now it seems to be covered with dust and didnât get proper attention recently.
Having a system to fine-tune load order easily as I suggest would dramatically simplify the codebase for small projects.
Being able to control load order means that the most important scripts will be loaded first and I can control that easily as well.
I just thought this was a nice option, especially for beginners. God it seemed so easy to get started on Meteor before, but since imports are a part of the Meteor tutorial, I see a lot more complexity from a beginnerâs point of view.
No worries. When systems scale, it becomes hard to chose what goes in and what not. For this reason its good to look at what users want. It probably seemed like a good idea to go import based, because the auto import version had issues regarding scale.
Unfortunatly this decision also impacted the entry level for new devs and prototypers
You can already fine-tune the load order by naming convention thanks to the rules of automatic loading here: https://guide.meteor.com/structure.html#load-order
ie. /lib/ first, then depth first search, each folder ordered by filename.
As soon as you create a file with a list of imports in order, you might as well use native importsâŚ
You can already fine-tune the load order by naming convention thanks to the rules of automatic loading here: https://guide.meteor.com/structure.html#load-order
I have a huge problem with that, since the file structure is the number one thing that makes a codebase understandable and clear. Iâve been dealing with having to prepend my filenames with numbers, just because I needed to gain control over the load order. Alternatively Iâve dealth with writing atmosphere packages that wrapped my app code just because in those packages I did have control over the load order.
I want to ppint out another thing. Learning curves are not a bad thing. They need to exist in order to make developers better. Not using imports and all of its benefits removes part of the required skills to properly structure applications and opens the next curve towards learning about NPM and dynamic imports / code splitting
On this I donât understand. Is it job protection? Because I would argue that every line of code you donât write, and every process you donât have to run will save you time and productivity.
It is good to learn but not for the sake of learning.
You learn to become a better programmer. Better in this case means knowing why imports are a good thing compared to all the issues described by @cloudspider. Writing those lines of code are good, because it solves an issue. It wonât save you time and productivity in the long run if you skip learning those steps.
You could also skip writing tests and be more productive at the start, but youâll pay for it later.
I get a feeling this is getting of topic though 
Absolutely. The OP has specifically requested that any further posts should be on-topic:
@antoninadert: please start a new topic if you want to discuss coding styles in Meteor.
This thread has gone on long enough.