
Funding Open Source: How Webpack Reached $400k+/year - naspeh
https://medium.com/open-collective/funding-open-source-how-webpack-reached-400k-year-dfb6d8384e19
======
infinity0
>> fuck webpack

>> sorry to hear you feel this way! [..]

>> [..]

When I first read the quote, I thought "that's nice of webpack". Then I saw
this:

> The greatest power you have for haters or trolls is love.

I would not call someone saying "fuck webpack" a hater or a troll, I would
call them a frustrated user. OTOH, you can turn a frustrated user into a hater
or a troll by dismissing their concerns or by trying to shift the blame onto
them by calling them rude.

Venting your frustration is an absolutely understandable behaviour when faced
with unintuitive software, especially for users who don't understand what
they're using (including software developers!) - they're in a position of
lesser power, feel helpless, and need an outlet to express this. No developer
should be taking these expressions as a personal attack, nor belittling it as
rude or trolling.

Because of this, I saw the original quoted interaction in a new light - upon a
second look, it is a bit unsubstantial, bordering on virtue-signalling. A
proper quote that _actually indicates_ caring about your users, would include
responding to a specific problem from a very frustrated user, by _actually
fixing the issue_. Not just saying nice words.

~~~
wellpast
I don't think it's acceptable in any situation to express your frustration
this way in a public forum, especially for OSS. Thoughtful critical pieces are
fine and necessary, but I don't think blatant vitriolic "cathartic" outlets
should be encouraged at all -- in this case, it is being encouraged by the
maintainer, but I don't think that helps anything.

I get the frustration...I've said "Fuck XYZ" a thousand times for a thousand
different software XYZs but to take that to a public forum is suitable
behavior for a toddler, and does harm.

How many nights & weekends were spent building Webpack? How many nights &
weekends coming up with "fuck webpack"? Show some respect and at least spend a
few hours in thoughtful critique. Civility must still have a place, even
online.

Tangentially, Rich Hickey recently responded (I think appropriately) to a
similar outlet re Clojure [1].

[1]
[https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/)

~~~
avenoir
I agree that screaming something like this on Twitter when you're in temporary
rage is nothing but childish. But it's also hard to ignore that someone who
represents webpack was able to resolve the situation calmly and civilly only
to call the person a hater and a troll later on. This, in my eyes, is a breath
away from screaming obscenities on Twitter.

------
bryanrasmussen
The difficulty I have with Webpack is that there does not seem to be any
unifying principle of how things work.

The stream model of gulp and the resulting highly structured code that most
often results means that I can generally find and fix bugs quickly, this is
even possible in the horribly convoluted gulp file that we use at my current
working place. In my experience when you have even a bit of webpack and there
is a problem somewhere it can be difficult to figure out the cause because it
seems every capability of the system works in its own way.

~~~
aphextron
Completely agreed. Webpack faces the exact issue that Grunt ran into which is
these huge 'config files of doom' that end up as snowflakes which are hard to
understand.

Rather, defining the build process entirely in code lets you step through the
whole thing logically.

~~~
ng12
I don't find that to be true at all. In fact I would guess that across all my
projects the configs are 80-90% identical. The only thing that changes are
different loaders depending in the tech stack and maybe the addition of a few
bells and whistles such as i18n.

------
stevebmark
The state of Webpack does not reflect a 400k/year budget. The docs, API,
source code, ecosystem... so happy to hear people making software engineering
money get a second salary to keep doing this.

We're all waiting for the thing that will replace Webpack so we don't have to
keep using it. Maybe we should just go and make it.

~~~
naspeh
I think it does. This area where webpack is trying to shine is just over-
complex, so the tool can't be simple, that's it.

And most importantly as for me, developers who works full-time on such
projects can sustain the higher quality and improve it over time and if you
chose it for now it may been relevant year later or 2-3... I hope at least.

~~~
thelarkinn
The tool aims to be agnostic to work flow it's a trade-off to be generic in
our case. We realize it too.

------
perpetualcrayon
"Ever since we were able to grow the budget large enough for Tobias to work on
Webpack full time..."

This is what the open source community needs. Steal the maintainers of the top
1% of open source projects from the "free market". The projects not already
sponsored by corporations that is.

Or, why not work toward pairing these maintainers w/ companies who will let
them spend most of their time working on said project. Might make it easier as
far as fund raising is concerned.

I bet there's a niche for this second idea. It's not always obvious to the
people cutting the checks just how valuable these side projects are to the
world.

------
zx2c4
Nice to hear there's some hope... I managed to get some small grants and
donations and things for WireGuard over part of this last year --
[https://www.wireguard.com/donations/](https://www.wireguard.com/donations/)
\-- but I don't have much lined up for next year, and I'm hoping I can figure
it out in time to do WireGuard things full time. The thing is just getting
funding lined up for [part of] this last year was a pretty time consuming
hustle, and I'd rather spend that time writing code. This leads me to think I
should find somebody to handle "fund raising" or "community mumblemumble" or
something, but as WireGuard is a security-oriented project, communicating
correctly is important, and I could imagine that somehow backfiring. The other
thing is that I'd feel really uncomfortable putting up one of those
thermometer overlays on the wireguard.com website; just adding the "donate"
link in the corner was a bit much for me. So, hm. Nice to see the Webpack guys
figure it out. Maybe I'll take some clues from there.

~~~
naspeh
Here is one more success story nowadays about Vue.js and Evan You (creator)

\- [https://medium.com/the-vue-point/vue-
in-2016-8df71d98bfb3#9a...](https://medium.com/the-vue-point/vue-
in-2016-8df71d98bfb3#9af5)

> _Going Independent_

> In early March I decided to work on Vue full-time independently and started
> a Patreon campaign, which has been (to my surprise) quite successful so far.
> It is my first time working independently without having to report to a
> manager, and it has been a very liberating experience.

They also use OpenCollective: [https://medium.com/the-vue-point/vue-is-now-on-
opencollectiv...](https://medium.com/the-vue-point/vue-is-now-on-
opencollective-1ef89ca1334b)

------
jondubois
It's a great project but I don't understand why they need so much money for
the future. It's a bundling tool. Wasn't it supposed to be a transition
project? Won't Webpack get replaced by simpler things like ES6 module import
and HTTP2 push?

It was the same thing with CoffeeScript; it inspired some neat features in
JavaScript but it has made itself obsolete; the ecosystem caught up. It
fulfilled its purpose nonetheless.

Webpack would probably have benefited more from this funding a few years ago.

~~~
acemarke
No, HTTP2 doesn't just replace bundling, and definitely not what Webpack does.

Based on what I've read, sending a few bundled chunks instead of many
individual module files will still generally have less overhead. In addition,
Webpack's ability to load and transform other file formats like images and
styles is something that simply requesting ES modules over HTTP2 can't deal
with. Webpack's ability to code-split an application is also important.

Tobias Koppers, the main Webpack developer, wrote an article last year on how
Webpack and HTTP2 relate: [https://medium.com/webpack/webpack-
http-2-7083ec3f3ce6](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6) .

It's also worth noting that Tobias had only been able to work on Webpack
intermittently for the last couple years, until this recent funding allowed
him to work on it full-time. Tobias has been writing reports on what he's been
doing [0]. Also, grants and full-time development is enabling the team to work
on projects like integrating WebAssembly support directly into Webpack [1].

[0] [https://medium.com/webpack/the-chunk-graph-algorithm-
week-26...](https://medium.com/webpack/the-chunk-graph-algorithm-
week-26-29-7c88aa5e4b4e)

[1] [https://medium.com/webpack/webpack-freelancing-log-book-
week...](https://medium.com/webpack/webpack-freelancing-log-book-
week-17-48233121afbe)

------
CloudYeller
So TL;DR: tshirts, ads embedded in their docs, and corporate sponsorships.
Makes sense for an open source project with a fairly large community at least.

------
marknadal
This is really encouraging to hear, I run an Open Source community that is a
fifth the size of Webpack. And in the back of my mind I'm trying to figure out
how to help fund/pay/reward the community, without then making it awkward,
political, or money driven.

How did you get the companies to sponsor? It seems like once you are above a
certain threshold/community level, it makes sense for a company, but did you
just reach out or was it people you already knew? Or people you bumped into
while talking at a conference? But how do you know if they are the ones at a
company that can sign off on sponsorship? This very much seems like "sales",
how does an Open Source-loving engineer get good at sales?

------
hguhghuff
Maybe they could employ a programmer who knows how to turn unbelievably
complex software into incredibly simple software that doesn't include constant
relentless breaking changes.

~~~
pandemi
How do you hire programmers like that?

~~~
techdragon
<stereotype joke> By not hiring a JavaScript developer. </stereotype joke>

More seriously... I've just today finished updating some C++ code that
integrates the Chromium Embedded Framework into Unreal Engine 4 to work with
current versions of both CEF and UE4 and even building all this, Separate CEF
sub process binaries without a strait forward make && make install, and debug
builds of the entire unreal engine editor to track down CEF initialisation
errors. Was simpler than React, Redux, WebPack, Babel, et.al. ... and I'm not
a professional C++ dev using it every day either!

I'm also not going to blame the language either. I sat down and worked through
the entire EmberJS documentation in a couple of afternoons worth of spare
time. It was clear, concise and orderly. It was easy and now I'm even looking
forward to EmberJS 3.0 with Glimmer and full support for building stand alone
web components using just the EmberJS ecosystem. So clearly it's not some
fundamental failure of my ability to learn/understand JavaScript.

So at the end of this joke/rant I guess I have to point my criticism at the
subset of JavaScript developers who have allowed the crazy parts of the
JavaScript ecosystem that they maintain, to get out of hand. I suspect because
they never stop working with it and consequently are able to hang on to the
rollercoaster and productively make use of it while being blind to outside
criticism because as far as they can see it's all simple and logical and it's
everyone else that doesn't understand it.

~~~
aaron-lebo
It just sounds like you found a quality C++ library, there's thousands that
are horrific messes. Compiling some of them is unbelievable amounts of
frustration, which npm mostly avoids.

Webpack works fine and is easy to use, part of the issue is that people
criticizing JS don't know what they are talking about because they don't
actually use JS that much and they don't understand why that makes their
criticism not that useful (not you, just in general).

JS has a magnitude more devs than some languages and a lot of them are new
users, with that being the case, it isn't shocking that it makes for a large
number of bad libraries. But if you know your tools, it's not that big of an
issue.

~~~
swsieber
Webpack is terrible to use. Very inconsistent and results in a mess of code
for your configuration. I suppose part of that comes from the 10+ loader
interfaces it uses under the hood. But most of it comes from organic growth (I
assume) and the fact that there are no JavaScript standards (e.g. no
filesystem or pipe like interfaces, the competing module systems and no
standard library)

This is a nice guide to starting with webpack that I think describes it very
well: [https://what-problem-does-it-
solve.com/webpack/index.html](https://what-problem-does-it-
solve.com/webpack/index.html) I'd recommend this guide to anyone who is trying
to get started with webpack.

I wish there was an intuitive way to chain JavaScript file transformations
together, but it doesn't seem like there is one yet. Webpack is close, but I
think it has too much baggage to get there.

~~~
Chyzwar
Webpack standardizes JS build process. It is a massive improvement from Grunt
- plugin dumpster, Gulp spaghetti code and makefile - DIY everything.

Issues you might have are related to broken web frameworks (angular4) than
webpack itself.

------
tzm
Thanks for making and continuing to improve WebPack. I use poi.js which uses
WebPack internally for low/no config dev.

[https://poi.js.org/](https://poi.js.org/)

------
jackmott
Why is it so slow with that kind of funding?

