Identify and Analyze Current Financial Status of OpenJS Projects

[UlisesGascon]

We need to assess the financial standing of projects within the OpenJS Foundation. This involves identifying all active projects under OpenJS and evaluating their financial resources, including available funding, expenses, and any external sponsorships or partnerships. The goal is to gain a clear understanding of each project's financial health to inform future planning, sustainability efforts, and resource allocation. Additionally, this data will help ensure transparency and support decision-making processes for the continued growth and success of OpenJS projects.

[voxpelli]

This involves identifying all active projects under OpenJS and evaluating their financial resources, including available funding, expenses, and any external sponsorships or partnerships.

Should also identify what the pain points / limitations are in funding for these projects – to inform where assistance and deep dives are needed.

[voxpelli]

Another aspect that I brought up in the meeting that I also think we should include is:

Identify and group projects on aspects which might affect how they can raise funds.

Personally I think there's a difference between platform and non-platform projects – eg. node.js does not appear as a direct dependency in projects that's based on it, excluding it from some funding sources (#5 (comment)) like Thanks.dev, Tidelift, StackAid but also making it of interest to an entirely different set of sponsors – the PaaS and cloud companies of the world. (Elaborated on the Node.js case a few months ago here: nodejs/TSC#1553 (comment))

I personally think that non-platform projects could also be divided into at least two categories: Dev tools and frameworks/libraries (maybe frameworks and libraries are also different enough to split)

Dev tools has traditionally seen lots of support on eg. Open Collective – ESLint, Webpack, Babel – where frameworks and libraries are generally less successful I think. This could be because the immediate value – the ergonomics, features etc – of a dev tool proves itself directly for developers in their every day work, whereas frameworks/libraries mostly prove their value in the product they help create.