This is a follow up to a post I published a while back about forking Meteor. I thought I was going MDG and the community a service, turns out the exact opposite. I had a conversation with @thea who leads community involvement at MDG. Here are our meeting notes (reviewed by @thea)
So how do we start this conversation?
We need to (if you ask me)
Identify community leaders for various parts of the ecosystem
Identify maintainers who will take the lead on Meteor components on Github
I want to clarify here that we are looking for contributors on all parts of Meteor (issue triage and documentation are a great place to start), and see who would be interested in contributing to the maintenance of components in the organization. We are not currently handing over maintenance keys like candy, but want to see who is interested in getting more involved.
Perhaps it would help if you identify the various parts of the ecosystemā¦ I feel like Blaze is getting started, the build tool seems like a thing MDG itself is working on, DDP feels like something that may go the way of the Dodo bird, what is left?
I would love to see an effort to revamp the accounts system, but even a small change like making the configuration screen optional has gotten bogged down in major discussion.
The account system that Meteor has right now should be overhauled, it should also include a way to do complex authorizations, access control - the works.
Then thereās the dream of enabling offline applications. And, desktop applications via Electron***. There are many other things on my wishlist too.
Iāll be happy to jump abroad your ship. Iām afraid I lack time to dive deeply into it just now. Iāll be happy to help with documentation* for the time being. Is there a list of things, in the context of documentation, you would like the community to work on?
Communications from MDG are really nice - forums such as these are rare where project creators and developers talk openly. This movements towards community-run stuff is very nice, it is the path that many major projects take (Ć la Apache projects).
I would, however, add that all of us need to know MDGās vision, itās short-term and long-term objectives, itās roadmap (I know you have a public roadmap somewhere on github right now, but I think itās very basic, it doesnāt give too many clues). Basically, it would be nice to share your SRS document with the world so that everyone knows what you guys are working on.
Iām good with LaTeX https://www.latex-project.org/, we could create a very robust and full PDF guide that comes with Meteor. We could take what you have now http://guide.meteor.com, we could add more content to it from many sources (Blogs like MeteorChef*, Github issues, etc) and make a PDF guide - I could help you with that. I know that others, like @awatson1978 have guides they manage too. MDG could think of creating special use-case guides.
@thea can you assist us? We had discussed over our phone call communication issues. I can sympathize with people having an eye for the future when making investment and commitment.
@dbx834, last I checked the docs were done with Github / HTML documentation tool. Are you ok with such tools?
Comms and community maintenance support is something Iām actively working on right now. Time frame for making improvements here is likely in the next few weeks (but not months). It helps to understand how people want to get involved, so the feedback here is very valuable.
Thank you @thea, can we have somewhere a community list we can edit that highlights contact points / leaders for different tasks. We have some great people here who are willing to contribute, I honestly believe we as a community need some more empowerment.
For instance, @joshowens has āvolunteeredā (I hope I am using the right word ) in prior post to help with user accounts (which will need some work to migrate to GraphQL) ā he has posted again here implying it may not have advanced much.
@ramez Are you thinking of placement on a GH readme? For now, it might work to collect a list of names and sticky within the community section, for example.
The reason I thought Github made sense is that it allows for communication. Peopleās profiles will allow users to find contributed repos etc. But whatever you can do now would be appreciated.
One of the most important contributions to Blaze, Incremental/Virtual DOM (basically speeding up rendering) is in a holding pattern, because a PR didnāt get accepted and disagreements between āvolunteersā.
I hope someone can step in and remedy that situation. I hope this doesnāt get stale and drop off ā because that will hurt Blaze IMO.
I like Meteor, and Iād like to share some of my thoughts and opinions on moving the framework forward.
I personally think Meteor was in a unique position but due to changes in the MDG priorities and the churn in the node ecosystem the vision for it got little foggy. Because of the ambitious of the initial founders and their emphasis on developer experience, I think it was the only framework with Node ecosystem that could be recommended to non-technical or busy technical entrepreneurs who needs to juggle businesses and technology and donāt have time to learn 50 micro libraries and keep up with themā¦the innovation of Meteor is that it made mobile and web development accessible for many and Iāve highlighted this point here
Please note this is just my personal opinion, so feel free to disagreeā¦
Moving forward I think Meteor community should continue pushing on this niche market it initially filled, meaning future meteor would be (or continue to be):
Simple: requires basic knowledge in JS, CSS and HTML to get started so it continues attracting a wide range of audience. It provides an easy way to start and deploy mobile (Cordova and PWA), web and desktop applications (Electron). Starting Meteor should feel just like editing HTML file to start withā¦perhaps in the future blaze can allow the creation of blaze components
Opinionated : it should come with accounts, routing, templating (blaze) a DB and a deployment script all ready so first time users can see their app running in few minutes ā¦I donāt think people should be presented with many options at the startā¦
Real-time, reactive and optimistic rendering enabled by default. This is the Meteor magic which we all loved! I donāt need to say more hereā¦
Scalable: I think RethinkDB it the right DB going forward because it fits Meteor objectives, I also think Meteor needs a good profiling tools as well as a set of best practices to handle large volume of transactionsā¦I think we need a scaling guide, what to do when an app reaches certain scale, or what what to do when
Long Term Support: people should feel that they can create a product with ease and the technology gets out of the way, and when their product get traction they can scale, and when their business stable theyāve the longevity and support
Atmosphere and easier NPM Integration: third party libraries should be easy to add, just like it used be with Atmosphereā¦itās really unfortunate to see Atmosphere samples and link broken, I think that was a mistakeā¦
Faster and smarter build tools: faster build times and the ability to split the code will be very important in the future with progressive web apps.
As stated before I think Meteor āClassicā should continue pushing on the niche it hasā¦making node ecosystem accessible to all. If people want other options or a much more flexible architecture, they can add Apollo, using React ecosystem, build their own stack, or even do everything in plain javascript, that is their choice and the node ecosystem has a lot to provide in that spaceā¦but I think there is a need for a framework to abstract those issues and make node accessible for all and Meteor has a great head startā¦
Just sharing my thoughts, and thanks @ramez for starting this conversation :)!
@alawi not going to move your comment to a new thread for now because I think itās a great one, but letās keep this thread to organizational logistics over project goals and/or philosophies. I think the latter deserves its own topic if others would like to discuss it at length.
Thanks @thea! my apology if I got off topic, I think youāre right it might have been better to keep the focus here on the logistics, and have another thread on goals and/or philosophiesā¦
Iām very excited by the prospect of Meteor splitting up and forming individual communities around different libraries. Now, comes the question of how we want to organize this.
First, titles: working on core Meteor projects is respectable, and thus, it should come with a title. That way, people can identify their work on LinkedIn, resumes, etc. Perhaps we should have a āMeteor Community Developerā title alongside āMeteor Core Developerā?
Second, managers: Meteor was designed by opinionated individuals, and was not intended to reflect the popular opinion. My worry with the open style of development is that it will shift towards the latter, risking complicated feature and bloat. Additionally, managing these projects for MDG might be hard. Perhaps Meteor should designate Project Managers for each library, and then that PM would manage and guide developers along the way?
Finally, incentives: Meteor is a commercial company, and as always, I believe there needs to be a reciprocal relationalship. As the community helps grow Meteorās market, and assists Meteor customers, what should they expect to receive in return for their commitement?
The post was encouraged from someone at MDG, and I think itās a interesting question, as we have an open source project with commercial interests. It would be great to hear what you think.
