Webpack.js.org: Why fund webpack?

[TheLarkInn]

We should give developers and CTO's a reason to really support and fund our open source efforts and community. To do this, I believe we could provide an entire section for this information targeted and tailored to multiple communities. Below is a very rough outline for how this information could be broken out into individual sections/pages.

Why fund (support?) webpack?

First and foremost, the people who contribute to webpack, do so for the love of open source, love for our users and ecosystem, and most importantly, pushing the web forward together. Because of our Open Collective model for funding and transparency, we are able to funnel support and funds through contributors, dependent projects, and the contributor and core teams. But what is the return on the investment?

Developers

Sales Pitch

maybe focus making it more enjoyable to develop through improvements, etc., help us fund rich and vibrant documentation, helps sustain the things they love about webpack already and gives a chance to impact that sustainability

How they can help support

(Sponsorship, Backing, Lobbying to Employer)

How Devs can Pitch Sponsorship to their Employers

Include a tiny slide deck, statistics, monetary figures, and script so Dev's can use as a selling point.

CTO's, VPs, Owners, (etc?)

Sales Pitch

maybe focus on the monumental impact that webpack has on developer productivity, innovation, and web performance patters. Give monetary numbers. (these could be generally referenced as $(Million) dollars saved or gained by using webpack). Talk about incentives for large sponsorships

How they can support as a company

links to open collective etc.

How else they can support our org

Encouraging developers to help contributing to the ecosystem, open sourcing tools and loaders and plugins, helping increase and support our CI/CD infrastructure. ETC.

VC, Government, Digital Agencies, etc.

Sales Pitch

More of a Marketing Flare: logo on our docs, logo on our github readme, exposure to one of the top NPM libraries.

[bebraw]

There's other side to pitch too - potential contributors. It would be good to open up the funding model and show explicitly it's not just some club. Instead of only supporting a tight knit core group of people we also support downstream projects and can support individual maintainers. You'll most likely end up with some onion style visualization to explain this idea.

Broadly interpreted funding can mean other things than only money. This includes developer time (companies borrow eyes for a while), computing resources (better CI, regression testing), and other tangible things that can produce value to the project in some way while keeping it healthy. Money alone might enable some of these things.

The more specific we can be about goals like these, the better. If you can explicitly state that we need a thinger to help the project, it's much easier to "sell" the idea and find a potential contributor or contributors.

[TheLarkInn]

There's other side to pitch too - potential contributors. It would be good to open up the funding model and show explicitly it's not just some club.

@bebraw Totally agree. I think those are _must haves_ on this page.

[scottdj92]

I'd add in a selling point for CTO's: using webpack decreases the amount of tooling you have to add into your projects. Fonts, images, and icon-fonts can be loaded using only webpack and plugins/loaders. Which makes it easier to grok and I don't have to rely on external tools.

We could market webpack as an all-in-one tooling chain + optimizer.

[TheLarkInn]

Excellent yes. I agree.

[dmitriid]

I'd add in a selling point for CTO's: using webpack decreases the amount of tooling you have to add into your projects. Fonts, images, and icon-fonts can be loaded using only webpack and plugins/loaders.

Unfortunately, this sells a pipe dream. Webpack _potentially_ reduces the amount of tooling. When extract-text-webpack-plugin silently removes all your code or typescript loaders cannot work on the whole codebase etc., you become very wary of what is invoked through webpack.

As a bundler of javascript code webpack is great. As a "replacement for a bunch of tools"? Not so much.

It "replaces a bunch of tools" with a bunch of plugins/loaders/weird combinations thereof. And don't get me started on the configuration of the all the moving parts required to "replace a bunch of tools". Or how webpack spills the guts of the plugins _and_ webpack on errors inside plugins (it's better in v2, but still). etc. etc. etc.

Do not oversell webpack. It's great, but very very very much far from perfect, and for every "tool replaced" introduces its own issues that are often much harder to deal with than in a bunch of tools.

[bebraw]

There's a support page now. Time to close this issue.