Should we make a community fork of Meteor?
mitar opened this issue · 22 comments
Meteor provides now a way to maintain a Meteor fork through meteor publish-release command. We should maybe create a fork which would be compatible upstream, but provide additional APIs which would help develop better packages and features. (Sometimes it is just enough to make something private a public interface, to be able to innovate.)
That could be a good because community could try out the API and code and then once satisfied with a particular change, we could ask Meteor to pull it into the core.
@mitar I've been thinking the same thing - when I did the bower release of meteor I wondered why they made the feature and been thinking that its a potentially dangerous feature. One could easily make a aws code deploy version of meteor + looking at the node community Im not 100% sure about forks.
I think it would be a good thing if meant as a friendly convergens to core - it could speed up evolution - but it should be seen as positive thing.
I wondered why they made the feature and been thinking that its a potentially dangerous feature
Easier it is to fork a project, less it will happen. :-)
I thought about it as purely positive thing. It would help determine what is really necessary to go into the core and minimize changes there, but also provide easy way for us who want to live on the edge to have something to work with.
I would agree with the edge thing - I guess if we isolated all the extra features on branches it would make it easier to maintain and to make pull - requests perhaps.
If forking, it should be managed in some way making it easy to maintain and stable.
The question about fork is: can you depend with a package on a fork. And if you do, does this force the whole app then to use that fork? If this is so, this would be a simple way to see what packages/features need a fork and which not, and users might not even notice that they are using a fork because they chose some package.
@mitar, would you like to add in the OP a list of features that would differentiate the fork? Basically it would be a combo of the issues you've raised within the last day, + things from the Meteor roadmap that the community actually wants, but can't create in the roadmap.
Oh, I don't know which exactly features should go there. But I was thinking more of a process. There is a known fork, with a known repository, where you can make a pull request, and things go in after community decides to do it. We could even use something like votebot for community to vote which pull requests get in.
The idea is that there is something in place. If I want to make a fork now for myself, it takes some time, I have to keep it updated, etc. If we would have one central one we could collaborate.
Can you make a link to a ticket for each of those, so that we can have discussion there about the content of the proposals themselves? (I have not seen few of them mentioned before and I would love to discuss it a bit.)
Updated issue references
As you could imagine, I've also been thinking about this possibility. Meteor-core is too slow to accept community contributions (for instance meteor/meteor#2386), and they don't share a lot of their work (eg most of their design document drafts on hackpad are private).
I've been considering joining MDG to contribute more actively to the framework (but I don't know if they want me anyway). Another possibility for me would be to contribute to a meteor community edition, but if we go on that way, we need to clarify our objectives and governance. Are we doing this fork because we're not happy with MDG, or we are happy with it but we just want to do some experiments (and breaks things)? What would be our criteria to accept new features? Do we keep the MIT license? How do we recruit contributors (do we reward them)? What is our release process?
Here is a list of features I would be interested in (in no particular order):
- Plugin API
- Javascript expressions in templates
- Source maps for templates
- New
package.jsformat (and rename it) - Incremental loading
- High level component API (@arunoda will certainly come to the rescue here ;-))
- Server-side rendering (↑ again)
- Blaze performance
- A more easy way to plug third-party database engines and keep a isomorphic API
- Package source code match the code published on github (I'll release something to solve this problem soon)
So that's a lot of work, and I think I'm not the only one interested in all of these features. I just need to think more in what the most efficient way to get them could be (taking into account that we have a great community).
Hey, I've been playing with easily basing a custom release using meteor publish-release on an existing meteor version. I can help on that front. I mentioned the current problem of doing this here:
Hi @rbabayoff I think I read your post when I did the meteor bower release - its about the only docs on it - thanks :)
Hmm.
I'm not happy with a fork at this stage. Here's the reason.
This is still a very small community and we don't need some divergence.
I believe some of these features can be implement as packages.
So, this is what I suggest.
- Fork meteor if only it requires and do few changes as possible as we can do
- We can expose and access internals API via MeteorX or similar
- we can make a new release make it looks like Chrome Canary
- So, this will be an experimental group for Meteor
- We should talk with MDG about this as well
@mquandalle why not contact them and apply for work at MDG :)
I agree with @arunoda. I think it makes more sense to be somewhat involved with MDG.
@arunoda I'm not 100% about a fork either - I agree that it would be nice if the community and MDG communicated / coordinated more about these things - but thats not the case yet, right?
I feel that a community fork is the absolute last resort if MDG becomes unreasonable for whatever reason
@zimme It depends on the purpose of the fork - as @mitar mentioned he wants it to be a positive thing helping us and mdg explore patterns and features - this could boost evolution.
If on the other hand the purpose is like in the node.js example - I would vote against - mdg is a bunch of reasonable people.
I'll chime in with also having thought about a fork or custom track. Specifically a stable version with complete testing coverage for FDA and CCHIT certification, and with a suite of packages catering to clinical application development. (A rough outline is at http://clinical.meteor.com/)
I think it's important to distinguish between track and fork. Most everything that @raix and @mquandalle suggest can be done in a track. A fork would suggest something even more low-level... such as a fundamental change in the Meteor tool or in Atmosphere. For instance, if the community really wanted to go back to a GitHub based package manager, I could see that as being a thorny enough issue that it might warrant a fork instead of a track.
So, I think I'm with @arunoda on this one. Fork as a last resort, and explore tracks in the meantime.
I feel like a community fork could cause more problems then it would solve. Thus far almost everything can be solved at the package level. That said I could see a fork for better/pluggable CLI and package settings/environments. Personally it has caused me a lot of grief not to be able to specify where a package goes.
Pretty sure a pluggable CLI is on their list, but feature requests are welcome now :)
@Kestanous I actually think everything could be solved at a package level if the build tool allowed it :)
if the build tool allowed it ~@raix
And thus the only remaining reasons I could see a fork. I am in no rush for better CLI so if MDG is on it then I can wait. Overall IMO I don't think we should fork.