Define clear goals/motivations of the Ayo.js project

[Sequoia]

In #56, @jmeas suggests opening the module loading discussion & @jkrems points out that the discussion already has a long history in Node.js and has been a source of much frustration and little progress. @jmeas follows up that it seems like a fork is a good place to discuss such things and continues:

I don't know all of the goals of Ayo...
- @jmeas

It occurred to me that I don't really know the goals of this project either, and it seems it would be a fundamental question when considering changes that would potentially break compatibility with Node.js

I've read compelling explanations from @zkat about corporate domination of governance and organizational ossification that made a fork necessary, so "make bold design changes that benefit users/contributors" seems like a possible Ayo goal. There's also the political motivations for a fork which I won't go into here, but "run a node-like project that prioritizes inclusivity/diversity while maintaining interoperability with Node.js" seems like another possible goal.

To enumerate the major branches as I see them here (please correct me):

• Branch A: "Ayo.js was created to break out of the organizational quagmire Node.js is in and to make aggressive changes to push the project forward technically. This will almost definitely eventually mean making non-interoperable changes; without allowing for this, Ayo is effectively chained to Node.js."
• Branch B: "Ayo.js was created to be a shadow-project of Node.js which is differentiated by having explicitly stated political aims (i.e. 'people over software' or similar). This project should keep interop with Node.js as a requirement to all development."
• Branch C: "A + B (more explicit political aims + willingness to diverge API-wise)"

Put differently:

• ☭ = politics/inclusivity (pardon the shorthand)
• ⎇ = willingness to break interop

	☭	⎇
Node.js	*	❌
Ayo A	❌	✅
Ayo B	✅	❌
Ayo C	✅	✅

* depends whom you ask-- not important for this discussion

Summary

It will be easier to approach and settle questions like #56 if it's clearly stated, in particular, whether Ayo is OK with breaking changes & whether the goal of Ayo is to address long-simmering challenges like this (I hope it is!).

There is demand for such changes [insert a bunch more complaints about promises here]. In this respect, explicitly defining "address long-running technical complaints with Node and break BC where necessary" as a goal of Ayo could provide users a really compelling reason to check out/use/get involved with the Ayo.js project, i.e. it could get the project off the ground and create momentum. Currently, it's not clear precisely what the project's goals are, and as long as that's the case, it seems unlikely to gain adequate popularity to sustain a project of this size/ambition.

[Sequoia]

Just found #7, sorry for not looking more closely at existing issues (this issue was originally going to be a comment on #56 but I realized it was a separate question).

I respectfully disagree w/ @varjmes here:

I think we've answered it well, in the form of our values document [VALUES.md].

"Is maintaining compatibility with Node.js a requirement of future changes to Ayo.js" is the main question not answered here, and which is crucial to understanding what Ayo.js is.

[zkat]

I think this is definitely a duplicate of #7 and it's something we've discussed a number of times now. I think the values document is the only concrete action you're going to get, and they don't include strict long-term compatibility with Node.js. They also don't preclude it.

I am not a member of the Core team, but my suspicion is that this question you have about compatibility will be answered on a case-by-case basis. Ayo.js, by virtue of being a newer/smaller project, has a unique opportunity to change course in a way that Node.js simply does not, and there are many people out there with a wide range of interesting needs.

I think it's safe to say that a reasonable level of compatibility is likely to be a long-term priority of the project, if only because losing access to an ecosystem of 550k+ (and counting) would be a terrible loss: but things evolve, and there's the possibility of being incompatible in some ways and compatible in others. I think mostly-compatible is the most likely scenario, and folks will probably factor in the likelihood of getting Node.js Core to merge those changes at some point in the future.

Now, keep in mind that one of our aims is to make it easier for project members beyond the core team to have significant influence over the project. I think getting a concrete promise like that right now about long-term decisions is... not really something that's feasible, realistically, but you can definitely advocate in favor of preserving compatibility as concrete technical questions come up. I assure you plenty of us genuinely care about preserving that. Myself included. As well as the likely members of the Core team. I'm sure these discussions will happen even if you're not the one bringing them up.

[zkat]

p.s. since it's a duplicate, I'd encourage you to close this issue. If the above answer is not satisfactory, I recommend opening a new one that focuses specifically on the issue of strategies for maintaining compatibility, rather than casting as wide a net as this issue did. Narrowing down conversation reduces noise and improves outcomes.

[Sequoia]

It's a project aimed at creating a new foundation of project governance and management

- values.md

OK- The goal/aim stated here appears to make clear that Ayo is a project whose primary output is governance models rather than software. I think that's a noble goal and I may have just not understood it at first!

I think my (and perhaps others') question is: "Node.js has a bunch of technical/API problems built up over time and with progress stuck due to BC requirements- can I expect Ayo.js to attempt to tackle these problems?" and it sounds like the answer is "probably not." This is not meant as a value judgement, just an attempt to manage my own (and perhaps others') expectations of and understanding of Ayo.js.

Per your suggestion, I'll close this issue ('lack of clearly articulated goals and motivations') as WONTFIX. I will leave it open a day or two longer in case others have relevant input that our discussion hitherto hasn't captured.

Also, I want to reiterate that "We're taking action on those long running, intractable issues that have been annoying you about Node.js for ages" could be a really good selling point for this project and bring a lot more people on board, and I do not think ⎇ is incompatible with ☭, or that values described in values.md would have to be compromised to add this goal.

[Mathspy]

Hello sorry for the slight high-jack, I am going to leave a short comment here just as a friendly reminder more than anything else in case anyone might be very eager for Ayo to be something very far and almost not compatible at all with Node due to forgetting the consequences:

We all suffered as web devs (specifically front end) hours that could sum up to months or maybe even years of our lives due to the profound incompatibility that we call front-end, and as IE and older browsers are finally coming to an end, with all the four giants and their browsers being regularly updated and following the latest, and also frequently updated, EMCAScript; these days are hopefully soon coming to an end.
Please, for the love of JavaScript and the sanity of all people who use it combined, whatever decision you take: remember those conveniences that we all, me included, want will often not save as much time as the incompatibilities they might waste. And going back in them is but more incompatibility nightmare for everyone. Please, don't replace callback hell with incompatibility hell, please

[brodycj]

The goal/aim stated here appears to make clear that Ayo is a project whose primary output is governance models rather than software.

I would vote for Ayo to be about both a (hopefully) improved governance model and a chance to deliver improved software. To me this should be the meaning of overcoming "red tape" as discussed in VALUES.md.

It would be really awesome to see a working workers feature ref: #58 delivered working soon, even at a pre-alpha level, as well as other "demand for" changes linked above: https://twitter.com/sebmck/status/908031616659927041 & https://twitter.com/BrendanEich/status/908068426999930880

I would also strongly agree with @Mathspy - avoid breaking things unless absolutely necessary as I said in #68 (comment).

[Sequoia]

@Mathspy & @brodybits: We all agree that we should avoid breaking things "unless absolutely necessary," I am certainly not suggesting breaking things for the sake of breaking things. 😄 I'm saying that some long-running node issues may require "breaking things" to fix them–moving the platform forward while maintaining 100% BC is proving to be a nearly impossible task (see nodejs/node).

1. In Consider additive systems for importing ES Modules #56 someone suggested opening a feature question that has possible interop-breaking solutions
2. Someone else said 'this has been discussed a lot already, let's not reopen the question'
3. OP said 'wait, isn't a fork precisely the place to reopen the question?'

This lead to my question "Is this fork a place to open such questions, is this fork willing to consider options that Node.js has rejected/quagmired?"

Leading/Following & Interop

Node.js is a party that is plotting a path, walking, travelling somewhere. Some people said "I don't like the way you're deciding the course this party takes. We're breaking off and forming a new party we'll call Ayo.js."

OK, so now Ayo is a different party from Node. Currently, the "Ayo party" is walking separately from the "Node party", but following directly behind them. So far, where Node chooses to go, Ayo follows.

In this analogy, "interop" is like the path you choose: if you want interop you must stay on the same path. Node is leading. Node is not going to change course to follow Ayo.* This means that if Ayo wants to stick close to Node (interop), Ayo must follow Node and this means following the technical decisions of the Node.js project. Ayo can neither add features that Node doesn't have, nor fail to implement features Node has. Effectively, this makes Ayo is a shadow-project of Node moreso than an independent project.

If Ayo is intended to be an independent project, it must be willing to part ways with Node. It must be willing to say "you're moving too slow, I'm going ahead" or "you're turning left, but we want to turn right." Otherwise all it can do is follow the decisions Node leadership makes, which seems to defeat the point of breaking away from Node in the first place.

* for the time being! If Ayo generates successful, popular improvements to the Node platform as io.js did, Node may wish to incorporate those back into Node and thereby "follow" Ayo. This can only happen, however, if Ayo is free to make changes and improvements that draw users and become popular.

Implications vis-a-vis feature development

If interop is a requirement, there's no point discussing feature questions in this repo: Ayo must follow Node, so all feature decisions will continue to be made in the node/nodejs repo by nodejs leadership. Example:

• Q: "How should we handle module loading?"
• A: "We have to do whatever Node.js does."

And that answer is the answer to basically every feature design question. Even the slightest variance/additions/omissions (e.g. "we'll make two ways to do it") will cause a divergence in userland code and therefor break interop of userland code.

So:

1. Can Ayo diverge from node?
2. If not, what's the point of discussing any feature development here, given that the answer is "we must follow whatever node does"?

[Sequoia]

@DelanoJ74: while I understand your concern and agree that there is some confusion here, it's not clear to me that there's any utility in hashing this out here. If you distrust the motivations of this project's founders, that's your choice, but I'd suggest that the best course in this case is just finding another project to work on. Why team up with people you seem to dislike or distrust? In any event I'd ask that you raise your question in a separate ticket; my question is primarily about the technical vision and goals of the Ayo project, not who said what when, about which I personally care very little. 😄

On Wed, Sep 20, 2017 at 7:39 PM DelanoJ84 ***@***.***> wrote: I think this is definitely a duplicate of #7 <#7> and it's something we've discussed a number of times now. I think the values document is the only concrete action you're going to get, and they don't include strict long-term compatibility with Node.js. They also don't preclude it. The disconnect between the stated reasons for the fork and the actual statements and the actual behavior that is tolerated by contributing members <https://github.com/nodejs/TSC/issues/325#issue-253509966> does, I suspect, contribute to this confusion. In essence, members will claim they created this project because they couldn't handle the toxicity and opaque leadership of Node.js out of one side of their mouths then either say or refuse to act on statements like this from the other: Y'all are about as spineless as you get. No wonder you never get laid. p.s. [LINK REMOVED] p.p.s. this thread is transparent as fuck and we're literally all laughing at your sorry asses behind the scenes. Yes, Node folks are doing this. I suspect what people are looking for when they ask for your rationale is less a boilerplate statement about the evils of toxic culture or opaque governance and more something which is actually comparable with your tolerated behavior. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATYOnwcAoldy8N8gj2l56oMYjfLNAmOks5skaIagaJpZM4Pbauz> .

-- Sequoia McDowell http://sequoia.makes.software https://www.linkedin.com/in/smcdowell

[bane-alex]

It's absolutely clear from the threads opened so far that there will be no improvement on the actual software side. This is just a drama fest presented by SJW types to entertain actual coders.

Edit from @scotttrinh: Trolling.

[TimothyGu]

@bane-alex You might want to check out #58.

Files changed (106)

+5,366 −858

[Sequoia]

Good luck & god speed!