Goal changes proposal

Describe your changes?

Merge webpack-command into webpack-cli to avoid confusing and duplicate development

Remove this.

Why are you proposing these changes?

There is plenty of room in the ecosystem for more than one CLI. Taking choice away from users for the sake of whatever you believe this will accomplish is ludicrous.

webpack-cli is quite frankly, poorly managed and a poor experience. It was a bad project when it was part of the core. It has been and continues to be a poorly managed and poorly architected project with a substandard user experience. Additionally, the main webpack org isn't managed nearly as well as webpack-contrib. webpack-command was created to escape the poor organization management and to address the myriad of shortcomings in webpack-cli. And even now, you have the primary maintainer of that project spending organization money to reproduce what webpack-command has already accomplished, and it's a personal affront that it's being directly supported by @sokra. If that isn't recognized as a prime, working example of poor management, then I don't know what else to tell you.

You may choose to defund webpack-command or not to support it, but you may not, under any circumstances, merge the codebase into webpack-cli. The level of which I and my efforts were mistreated, the absolutely abhorrent communication, and the back-room discussions held without my involvement on the future of this project were and still are unacceptable.

I would even go so far as to say I would be happy to have the repo ownership transferred back to my personal account and maintain it on my own.

As the author and primary contributor I do not consent to webpack-command being merged into webpack-cli.

I want to note for the record here that I gave @TheLarkInn multiple opportunities to have an actual, real discussion with me about this, yet no discussion ever occurred. I'm extraordinarily disappointed in the leadership of webpack, or general lack thereof. Without my consent, you're copying my work. And that would appear to go against the goal of "Be an example for a good sustainable Open Source project"

You all should know better, and should be better than this.

There is plenty of room in the ecosystem for more than one CLI. Taking choice away from users for the sake of whatever you believe this will accomplish is ludicrous.

Yes there is probably room for multiple CLIs, but I think it doesn't make sense to have two official ones. Especially there isn't much reason to pay for two CLIs. Joining these efforts would make much more sense.

webpack-cli is quite frankly, poorly managed and a poor experience. It was a bad project when it was part of the core. It has been and continues to be a poorly managed and poorly architected project with a substandard user experience.

That's your opinion and I invite you to discuss and address these issues together with the maintainers and other contributors.

And even now, you have the primary maintainer of that project spending organization money to reproduce what webpack-command has already accomplished,

You also spent organization money to reproduce what webpack-cli did while creating webpack-command. But you pointing out that right problem. Two CLIs cause duplicate development. That's why they should be merged.

You may choose to defund webpack-command or not to support it, but you may not, under any circumstances, merge the codebase into webpack-cli.

As the author and primary contributor I do not consent to webpack-command being merged into webpack-cli.

Without my consent, you're copying my work. And that would appear to go against the goal of "Be an example for a good sustainable Open Source project"

This attitude makes me a bit angry. The "Open" in "Open Source" stands for open. Open Source is about sharing code, remixing code. You published your code under MIT, which allows remixing. The JS Foundation demands us sharing code under an open source license. The "non-profit" status of open collective demands us to publish code as open source. You used the money of our sponsors to develop this and they expect us to release open code. Because of this statement we may get into legal trouble.

If you really like to continue with this setting you better remove your code from the organization and publish it with a more restricted license.

I want to note for the record here that I gave @TheLarkInn multiple opportunities to have an actual, real discussion with me about this, yet no discussion ever occurred. I'm extraordinarily disappointed in the leadership of webpack, or general lack thereof.

I can't talk for @TheLarkInn, but I didn't know about that. Maybe he can comment here.

Some other comments:

I don't want to discuss about which project has more features or is "better" in general. This goal is about avoiding duplicate work and working together. While merging the team may choose to do whatever they want to. I fine with refactoring, breaking changes, etc. It's about joining work and not wasting money.

The reasons for merging webpack-command into webpack-cli are the following:

webpack-cli was created earlier
webpack-cli is a monorepo which should make merging easier
The name webpack-cli makes more sense for an CLI for webpack
More users are currently using webpack-cli. I want to cause as less user trouble as possible.
In the last month more contributions happens in the webpack-cli repo compared to the webpack-command repos.
I repeat this point because it's the most important in my opinion: It's easier for users to stay on webpack-cli than to migrate to another project, even if breaking changes occur.

Yes there is probably room for multiple CLIs, but I think it doesn't make sense to have two official ones. Especially there isn't much reason to pay for two CLIs. Joining these efforts would make much more sense.

I guess you missed where I said "You may choose to defund webpack-command or not to support it"

That's your opinion and I invite you to discuss and address these issues together with the maintainers and other contributors.

Tried it. Legitimately. The lead at the time was not interested in the proposed changes. The result of which was webpack-command. Quoting the original post "webpack-command was created to escape the poor organization management and to address the myriad of shortcomings in webpack-cli"

You also spent organization money to reproduce what webpack-cli did while creating webpack-command.

A complete rewrite in a completely different direction is not a reproduction. Supporting command line flags and executing a CLI is not a reproduction. What you are doing with webpack-cli now is a reproduction of webpack-command and all of the innovations that exist in it as compared to webpack-cli. You're just attempting to wrap it in ribbons to justify your position. That'd be like saying koa just reproduced express.

This goal is about avoiding duplicate work and working together.

That's a lovely sentiment - but your actions speak to the contrary. You had the opportunity to include me in the decision making process before you outright tanked the merge proposal. You could have asked the maintainer who objected to work through the proposal for merging the projects and ask for changes. He could have grown a spine and asserted his objections. He could have garnered support from the other maintainers involved and asked for renewed discussion. As the author of webpack-command you should have involved me before shutting down the merge proposal. But you didn't, and that speaks to the poor management of the project as a whole. And now you want me to be warm and fuzzy with your plan to merge my hard work into something that's still managed poorly - That makes total sense [sarcasm].

Listen, I'm not surprised you're defending your actions. You know it's wrong, but I know you don't care. It's the same kind of behavior and disregard from you that I've observed over the course of the last 18 months being involved in the project, and I expect nothing less moving forward. There is a severe deficiency in the recognition of abrasive, unwise unilateral decision making in the project (and how it effects other individuals) that makes this a back-room dictatorship. There's the veil of a democratic project, but with an all-powerful director in place that can torpedo any initiative at a whim. (It's a damn shame too, because the community is really great, and I wrote all that code for them and to improve for the community what the project was lacking.)

I've also no doubt that there are many folks that will come to the support of your reply who will follow you in lock step regardless of the position. There will be others that probably blast mine. And that's OK. You made a poor choice of involving yourself and making a unilateral decision, when several adults could have worked through a process that was already being discussed, and you made a poor choice of stepping in when you could have simply directed the person who was unhappy to garner support for his position.

You fucked up, man. There's no other way to put it. And this isn't the first time, and I'm not the first maintainer/contributor to be turned off and pushed away because of it.

If you really like to continue with this setting you better remove your code from the organization and publish it with a more restricted license.

The wording here makes it difficult to understand what you're trying to convey. But I will repeat the statement from my original post, for the sake of saying that; I'm happy to maintain the webpack-contrib projects I started on my own moving forward, outside of the webpack organizations and without funding.

More users are currently using webpack-cli. I want to cause as less user trouble as possible. ... It's easier for users to stay on webpack-cli than to migrate to another project, even if breaking changes occur.

Well, 'wading in', as "just a user" ... since, as a user, "I" seem to be getting "spoken for".

Like it or not, a webpack "command line" touches everything webpack-y we do. So this "little issue" quickly percolates to the top of the stack.

I recently found, and switched to webpack-command.

I did so BECAUSE it solves technical problems that weren't, and afaict still aren't, getting addressed. AND, that it appeared to be a responsive, well managed, project.

Simply, it works for me. Webpack-cli, currently, does not.

As a webpack user, I wasn't the slightest bit confused, or otherwise troubled, by the existence/availability of webpack-command. In fact, I was quite pleasanlty surprised to see it as "an official option". After the issues I'd been having with -cli, it was nice to see some cognizance of that.

What is troubling it THIS^. The facts are that webpack-command DOES fill a need: imo -- and apparently for numbers of others that consider & use it.

I can't speak to any of the history of the politics here.

I can say that if any of that^ is true -- and given the fact of the merge-it-back proposal I've seen, I suspect that it might well be -- then, as "just a user" THAT is the source of the confusion, not the fact that webpack-command exists, is apparently functionally different and well developed, and is an alternative -- official or not.

Imo, there's a big difference between being a project lead for a big project, and providing leadership to a big project.

Tried it. Legitimately. The lead at the time was not interested in the proposed changes. The result of which was webpack-command. Quoting the original post "webpack-command was created to escape the poor organization management and to address the myriad of shortcomings in webpack-cli"

This is entirely untrue. In fact, when webpack-command was being authored before my eyes, I urged you to show, ask, and encourage this work be instead built into the cli in April. At the least I asked that you work towards an end goal of merging this project back into the cli ( even if it meant fully rewriting it ).

My point on the offtopic piece of this discussion:

Andrew, @shellscape, I've had a lot of opportunities to try and reach out to you on this however, sure I dropped the ball and put 1000 other priorities in front of it. So for that I'm sorry, maybe I could have solved this problem sooner.

At the end of the day to all of this, I share the sheer disappointment with @sokra over this selfish, non-user-centric commentary via github, communications, twitter that you have provided. In addition the complete lack a concept known as: "disagree, but commit".

As different people we are going to disagree with decisions, but rather then running away, forking a project, and then denouncing the former, promoting your own ideas, rather, you work together as a team to achieve something as a consensus [even if you don't agree with it] and then execute on it.

Instead what I've seen, is when your "extra money" gets compromised, you instantly show your zero loyalty for this project and look for ways to instead support something else. This isn't user-centric. This is Andrew-centric. These kind of actions also give fire to people and companies to not sponsor a project because they believe that money brings the people who only care about money, not webpack and its users. You are proving their case with this behavior.

A great example would be the fact that you forked webpack-dev-server because of a petty ass argument over 7 vars vs const & lets that were breaking previous builds after you spent a considerable amount of time making changes to the underlying system.

Instead of just humbly accepting the fact that we have users who rely on old browsers, instead of being empathetic to that, you decided to "do your own thing, your way". You even closed PR's offering to fix this. In my opinion, is completely unacceptable to begin with. There is no excuse good enough to justify this action regardless of how much "better", "cleaner", webpack-serve is. Honestly I've tolerated this kind of behavior because I see that your work is great, and overtime your soft skills have very much improved.

To the main point here:

And it's not like we are talking about not using webpack-command. It's obvious that people very much like what the tool can do, however it should be built into the default cli experience that we have for users. A user by default, "zero-config", shouldn't even have to choose between one cli or another. That is absurd.

Man, this just goes to prove my point. You all are focusing on the all the wrong things.

This is entirely untrue. In fact, when webpack-command was being authored before my eyes, I urged you to show, ask, and encourage this work be instead built into the cli in April. At the least I asked that you work towards an end goal of merging this project back into the cli ( even if it meant fully rewriting it ).

Check your memory. That discussion, and the development on webpack-command in Salt Lake was after multiple attempts had already been made to affect chanage. You are incorrect.

you work together as a team to achieve something as a consensus [even if you don't agree with it] and then execute on it.

You might want to share that sentiment with the webpack lead. The irony is thick - if you truly believe that then why the back room discussions on webpack-command and subsequent torpedoing of the effort without discussion involving all involved parties? I don't think there was conspiracy, rather that you just screwed up royally - and still won't own up to it.

Instead what I've seen, is when your "extra money" gets compromised, you instantly show your zero loyalty for this project and look for ways to instead support something else.

I'm sorry, but you are completely off base. Money has absolutely nothing to do with this. Supporting multiple bundlers and getting involved in multiple projects across open source is bad how? I have an enthusiasm for it. I want to see what others are doing. I want to help improve the user experience for anyone I can. I'm contributing to Rollup at the moment because it's a fun project with a cool direction, FANTASTIC LEADERSHIP, and contrary to your claim I'm greedy, Rollup doesn't pay contributors. I've offered several times to have the repos transferred out and maintain them with no funding. Your response completely lacks focus and smacks of pettiness because you don't like what's being said - so you attack me based on greed? The evidence says otherwise. I disagree with the direction and leadership of the project. This also raises an eyebrow, and anyone reading this should really closely examine - how does involvement in other projects somehow call into question "loyalty"? Why is a project trying to assert itself as a state for which a person can only have "loyalty" to one? Why can a rising tide not lift all ships? I think that demonstrates a pretty severe deficiency.

Additionally, the non-action on any dissenting opinion from within the webpack contributors nor from in the core team was precisely the reason I made my thoughts public. I dissented, therefore I must be a money-grubbing bad guy.

A great example would be the fact that you forked webpack-dev-server because of a petty ass argument over 7 vars vs const & lets that were breaking previous builds after you spent a considerable amount of time making changes to the underlying system.

Man, you're really showing some ignorance here. It's not even a fork - it's a complete rewrite. I disagreed with making the exceptions for browsers that couldn't support the new variable types, yes. But the creation of webpack-serve was never about that. It was the fact that we couldn't use any new technologies like WebSockets, the config management was atrocious, and the way the client scripts handling HMR were written and deployed**_. The client scripts for webpack-server are even compiled down to ES5, and have been since it was launched. Honestly man, that just shows you have a complete lack of knowledge as to the evolution of these issues, and are showing a real disconnect with the ecosystem that you say I don't actually care about.

A user by default, "zero-config", shouldn't even have to choose between one cli or another. That is absurd.

As you can see from the random user above, no one is having to choose. They are making a conscious decision. There are people who don't find it confusing, even with your assertion.

Conversely, I express my sheer disappointment with how you all have handled the situation. That you've chosen to attack my character speaks volumes to me, and it should to anyone else reading this. An accusatory, absentee landlord suggesting that I did it solely for the contribution money, that I don't have any passion for the community, and that my goals were never genuine. That somehow my interest in improving user experience across the space are somehow damaging and proof that I don't care, or to suggest that evidence that I'm "running away" are flat out sad.

You can be better than that. You should be better than that.

Instead what I've seen, is when your "extra money" gets compromised, you instantly show your zero loyalty for this project and look for ways to instead support something else.

Wow. It's ... interesting ... to hear one of the project's supposed 'sages' make accusations, apparently unfounded?, about greedy-motives.

Sadly ironic that the same persons warning about 'bad behavior affecting funding' are acting in a way that, from where a user might sit, causes some pause in willingness to fund.

And noteworthy to read:

https://medium.com/open-collective/funding-open-source-how-webpack-reached-400k-year-dfb6d8384e19

Can't help but leave me to wonder exactly whose directlion/motives are ... profit motivated.

And yes, certainly not my project. And noone's asking my advice. But the beauty of (properly managed) opensource is -- people's opinions, whether you like them or not, get a voice, even if not heeded.

So, one question, then I'm outa here, to simply hope the adults all gather in a room and work this out:

Who here, exactly, is meeting $users needs with any of this? And who isn't?

Our motivations are to reward those who are loyal to the project as consistent contributors.

Our goals are not to be incentivizing work for the sake of money.

The latter breeds the kind of things we've seen in this dialogue and to be honest I think you are right.

And noteworthy to read:

I helped them author the entire article so I have read it unless you are referring to others. You are spot on that the best tool as a maintainer is love.

To answer your last question. No needs are being answered by this.

Therefore, we will merge webpack-command into webpack-cli. We'll look forward to changes contributions if willing but at the end of the day, and we'll lock this thread to prevent anyone else like myself, from getting heated or emotional and letting it distract and misdirect us from the real end goals here.

The work done on webpack-command and webpack-serve are paid work that was done for the webpack organization and signed over to the webpack organization via JSF through your CLA signatures. As the person who originally authored it @shellscape you can at the most recommend we do not merge it, however, at the end of the day if the organization sees it fit to merge this code in with the cli, we have every right to do so.

I've hidden previous off topic discussions from myself and you that we're irrelevant for this thread. We as a team will take the recommendation into consideration at best, and weigh in as we continue to work towards the goals we have set out in the management page.

webpack / management

webpack-command may not be merged into webpack-cli #1

Goal changes proposal

As the author and primary contributor I do not consent to webpack-command being merged into webpack-cli.

As the author and primary contributor I do not consent to webpack-command being merged into webpack-cli.