DEV Community: Shinigami

OSS Funding Is Broken — A Maintainer’s Perspective from FakerJS

Shinigami — Thu, 26 Mar 2026 07:36:18 +0000

A few days ago, I came across another familiar message in the open source world: a widely used project announcing that it can no longer compensate its contributors.

This time it was Vuetify.

But honestly, it could have been almost any project.

This Is Not an Isolated Case

If you’ve been around open source long enough, you’ve seen this pattern repeat itself:

A project becomes popular
It gains thousands (or millions) of users
Companies quietly depend on it
Maintainers keep it alive in their spare time
Funding either stagnates… or disappears entirely

We’ve seen this with projects like FakerJS, and we’re seeing it again now. Not just with one ecosystem either—this spans frontend, backend, tooling, infrastructure… everything.

This isn’t a coincidence. It’s a structural problem.

The Myth of Optional Funding

There’s a common assumption in open source:

“If a project is valuable, people will fund it.”

In reality, that’s rarely how it plays out.

Funding is treated as optional:

Optional for companies using the software
Optional for individual users
Optional for the ecosystem as a whole

But the work itself is not optional.

Maintainers still need to:

Review pull requests
Triage and respond to issues
Fix bugs and security vulnerabilities
Keep dependencies up to date
Make releases and maintain stability

When funding is optional but the work is constant, the result is predictable: burnout, abandonment, or stagnation.

What I’m Seeing as a Maintainer

From my perspective working on FakerJS, I’ve started to rethink what “sustainability” actually means.

Relying purely on donations, sponsorships, or platforms like OpenCollective is fragile. It works for a small number of projects—but it doesn’t scale across the ecosystem.

So instead, I’m shifting my mindset.

1. Time > Money (Sometimes)

Rather than depending solely on financial contributions, I’m trying to secure time.

For example:

Convincing my employer to allocate work hours to OSS
Contributing during natural downtime at work
Treating maintenance as part of my professional output

In this model, my “funding” becomes time that’s already paid for.

It’s not perfect, but it’s far more predictable than hoping for donations.

2. Community Contribution Is Undervalued

If money isn’t reliable, then community becomes critical.

And I don’t just mean code contributions.

We need more people to:

Review pull requests
Reproduce bugs
Help triage issues
Improve documentation
Answer questions from other users

Maintainers shouldn’t be the bottleneck for everything.

A healthy project distributes responsibility.

3. Maintainers Are Not Support Teams

One subtle but important shift:

Open source maintainers are often treated like unpaid support engineers.

That expectation doesn’t scale.

If you rely on a project in production, there’s a responsibility to:

Contribute back (code, time, or funding)
Reduce noise (clear issues, reproducible examples)
Respect maintainers’ time

Otherwise, the system collapses under its own weight.

Rethinking Sustainability

I don’t think there’s a single solution to OSS funding. But I do think we need to move away from the idea that donations alone will fix things.

A more realistic model probably looks like a combination of:

Employer-supported contribution time
Strong community involvement
Selective sponsorships where they make sense
Better expectations from users and companies

In other words: sustainability through participation, not just payments.

Why I’m Sharing This

I’m not writing this as an official statement from FakerJS.

This is just my personal perspective as a maintainer navigating the same challenges many others are facing right now.

Seeing projects repeatedly struggle with funding isn’t surprising anymore—but it should still concern us.

Because every time a project burns out, the entire ecosystem feels it.

A Small Ask

If you’re using open source (and you are), consider:

Contributing in non-code ways
Helping reduce maintainer workload
Advocating for OSS time within your company
Supporting projects you depend on—financially if possible, but not only that

Open source doesn’t survive on good intentions.

It survives on people showing up.

If you’re a maintainer feeling the same way, you’re definitely not alone.

Prevent Hidden Merge Conflicts

Shinigami — Fri, 28 Jun 2024 14:09:16 +0000

What are Hidden Merge Conflicts?
- Example 1: Function Signature Changes
- Example 2: Database Migrations
How Can They Be Prevented?
- GitLab
- GitHub

This article will use the term Merge Request (MR) as it is called on GitLab, but it is equally as relevant to GitHub's Pull Request (PR)

What are Hidden Merge Conflicts?

Assumptions:

We aim to maintain an evergreen main branch.
We work on features, bug fixes, and improvements on branches in MRs.

Hidden merge conflicts occur when changes in one merge request (MR) indirectly impact another MR without direct file conflicts, leading to potential issues in the main branch. Let's explore two common scenarios.

Example 1: Function Signature Changes

Assume multiple MRs are open. One MR changes a function's signature in a file not touched by another MR, but this second MR uses the altered function. When the first MR is merged, the second branch is now a commit behind. Without "Fast-forward merge" in GitLab or "Require branches to be up to date before merging" in GitHub, the CI doesn't rerun before merging. Consequently, the second MR can be merged without detecting the break (hidden merge conflict), potentially causing the main branch to fail due to the signature change.

Example 2: Database Migrations

Consider two parallel MRs, each adding a new database migration file. For example:

MR1: 002_add_person_table.sql
MR2: 002_add_company_table.sql

If MR1 is merged first, MR2 is unaffected. However, when MR2 is merged, its migration file (002_add_company_table.sql) is alphabetically before MR1's (002_add_person_table.sql). This leads to a migration conflict due to the execution order stored in the migration table or the tool raising a conflict for duplicate 002 definitions. Thus, the main branch fails again.

How Can They Be Prevented?

GitLab:

Go to Repository > Settings > Merge requests:
Under "Merge methods" select "Fast-forward merge":

GitHub:

Go to Repository > Settings > Branches:
Add or Edit "Branch protection rules" for your main branch:
In "Protect matching branches" select "Require status checks to pass before merging" and then "Require branches to be up to date before merging":

By configuring these settings, you can effectively prevent hidden merge conflicts and maintain a stable, evergreen main branch.

Limitation:
This does not prevent issues like changes of global CSS affecting the new component

Giving away a repository with 85k npm downloads a week ✨

Shinigami — Wed, 08 May 2024 07:00:44 +0000

Some years ago I took over vue-gtm, a Vue 2 plugin to simplify integration of Google Tag Manager into your Vue project. ⚡️

Years later I got bigger and bigger in Open Source and I feel that I do not have enough spare time anymore to maintain this plugin anymore alongside my other projects (@faker-js/faker, node-pg-migrate, @prettier/plugin-pug, eslint-define-config and many more). 📚

Additionally, I do not know very much about Google Tag Management as well as Google Analytics. 📈

However there are now new versions out for Google Tag Management and I cant keep up with maintaining.
So I would like to hand over the full https://github.com/gtm-support GitHub organization to someone else.
If you are interested, please send a comment below. I will also give a full introduction into the source code (it's not that much 😇) potentially via Discord.

Feel also free to share this post, so it gets some visibility.

How to setup Prometheus Metrics for NestJS GraphQL

Shinigami — Wed, 16 Nov 2022 10:19:43 +0000

TLDR: https://github.com/Shinigami92/nestjs-prometheus-graphql

Start of this week (14. Nov 2022) I needed to setup Prometheus + Grafana for an API-Gateway in my company.

I was afraid that nearly nothing already exists out there 🙀 and I only had this (spoiler: broken) guide https://hodovi.cc/blog/nestjs-apollo-graphql-prometheus-metrics-and-grafana-dashboards

The whole code examples on that blog article are not just copy&paste-able but also stale/broken.

So I needed to put some hard work into how to wire everything up and to safe hopefully some work for other devs like me, I created now a sample minimal reproducible repository and this dev.to article.

If this helped you at any time, feel free to sponsor me a cup of coffee ☕️ PayPal or via https://github.com/sponsors/Shinigami92

I assume you already have a running GraphQL NestJS app, so I will skip these steps, otherwise please follow the instructions at https://docs.nestjs.com/graphql/quick-start

First we need to install some dependencies:



npm add @willsoto/nestjs-prometheus prom-client # The general Prometheus metrics provider which will expose the endpoint /metrics
npm add apollo-metrics apollo-tracing@0.15.0 # Provides Apollo GraphQL server plugins
npm add --save-dev apollo-server-plugin-base # Contains the ApolloServerPlugin interface

Now we will add a module file src/metrics/prom.module.ts



import { Module } from "@nestjs/common";
import { PrometheusModule } from "@willsoto/nestjs-prometheus";
import createMetricsPlugin from "apollo-metrics";
import { plugin as apolloTracingPlugin } from "apollo-tracing";
import { register } from "prom-client";

export const TRACING_PLUGIN_KEY = "TRACING_PLUGIN_KEY";
export const METRICS_PLUGIN_KEY = "METRICS_PLUGIN_KEY";

@Module({
  imports: [
    // Register the general Prometheus module
    PrometheusModule.register()
  ],
  providers: [
    {
      provide: TRACING_PLUGIN_KEY,
      // Provide the apollo tracing plugin
      // This is only needed if you also want to measure timings
      useValue: apolloTracingPlugin(),
    },
    {
      provide: METRICS_PLUGIN_KEY,
      // Provide the apollo metrics plugin
      useValue: createMetricsPlugin(register),
    },
  ],
  exports: [TRACING_PLUGIN_KEY, METRICS_PLUGIN_KEY],
})
export class PromModule {}

The tracing plugin is only needed if you also want to measure timings of your field resolvers. At this time, there is NO Grafana Dashboard that will display this data. Maybe I will create one in the future, but for now at least just lets collect these additional data.
The tracing plugin will be used here apollo-metrics index L124

Now we need to register the PromModule in our AppModule



import { ApolloDriver, ApolloDriverConfig } from "@nestjs/apollo";
import { Module } from "@nestjs/common";
import { GraphQLModule } from "@nestjs/graphql";
import { ApolloServerPlugin } from "apollo-server-plugin-base";
import { join } from "path";
import { AppController } from "./app.controller";
import { AppService } from "./app.service";
import { CatsModule } from "./cats/cats.module";
import {
  METRICS_PLUGIN_KEY,
  PromModule,
  TRACING_PLUGIN_KEY,
} from "./metrics/prom.module";

@Module({
  imports: [
    // Import the PromModule generally (e.g. also for other metrics like non GraphQL stuff)
    PromModule,
    CatsModule,
    GraphQLModule.forRootAsync<ApolloDriverConfig>({
      driver: ApolloDriver,
      // Import the PromModule for GraphQL
      imports: [PromModule],
      useFactory: (
        // Use provided plugins injected from below
        tracingPlugin: ApolloServerPlugin,
        metricsPlugin: ApolloServerPlugin
      ) => ({
        debug: true,
        introspection: true,
        playground: true,
        // Plugins added to apollo server
        plugins: [tracingPlugin, metricsPlugin],
        autoSchemaFile: join(process.cwd(), "src/schema.gql"),
      }),
      // We need to inject the provider keys
      inject: [TRACING_PLUGIN_KEY, METRICS_PLUGIN_KEY],
    }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Warning: It is important to provide the plugins via that way, as otherwise if not registered to the NestJS context e.g. E2E tests will fail because the prom-client can only register a metric name once and will fail if a plugin tries to recreate a metric.

Now we are ready and just need to connect our metrics endpoint to Prometheus and then add Prometheus as Datasource for Grafana. (Please watch some other tutorials for that)

Now import the Grafana Dashboard: https://grafana.com/grafana/dashboards/16188-graphql-metrics

⚠️ But attention! ⚠️ You need to reconfigure the parameter operation_name to operationName (snake_case to camelCase)

The blog article https://hodovi.cc/blog/nestjs-apollo-graphql-prometheus-metrics-and-grafana-dashboards was manually using its own metric names 🤷

Please let me know if this was helpful and leave some comments.

Edit

I started to edit the dashboard provided by Adin Hodovic and extended it with tracing/timing panels.

Grafana Dashboard (json export): https://github.com/Shinigami92/nestjs-prometheus-graphql/blob/main/ApolloGraphQLMetrics.grafana-dashboard.json

I tried to publish it at grafana.com dashboards, but somehow the upload does not work 🤷

GitHub Contributors Map

Shinigami — Sun, 25 Jul 2021 17:55:34 +0000

Ever wanted to know if there are some repository contributors in your area?

Find out with my new project GitHub Contributors Map!

The website is still very young and I have not yet decided how to design it 🤔

Also, there are some minor mistakes in finding the correct latitude and longitude for some people 🤷

If you want to help me, you are very welcome 😃

Screenshots for vitejs/vite:

Creating an axios service wrapper (in Vue)

Shinigami — Tue, 15 Jun 2021 18:54:39 +0000

Today, I want to show you how we can create a REST API service abstraction in the client.
These are more refactor-safe, decoupled and can be e.g. unit tested.

Project Structure

Create a basic vue project and add a services folder in src

src/
  assets/
  components/
  composables/
  plugins/
  router/
  services/  <-- This will hold our API services
  shared/
  store/
  views/
  App.vue
  main.ts

The Abstraction

First, we create an abstract class AbstractApiService in src/services/AbstractApiService.ts.
This contains the axios instance and will serve as a wrapper. It contains helpful functions that handles errors and other stuff.

So we add a http: AxiosInstance as a property, a constructor and these helper functions.

import type { AxiosError, AxiosInstance, AxiosResponse } from 'axios';
import axios from 'axios';

export function isAxiosError(value: any): value is AxiosError {
  return typeof value?.response === 'object';
}

export abstract class AbstractApiService {
  protected readonly http: AxiosInstance;

  protected constructor(
    protected readonly path?: string,
    protected readonly baseURL: string = import.meta.env.VITE_BACKEND ?? '/'
  ) {
    if (path) {
      baseURL += path;
    }
    this.http = axios.create({
      baseURL,
      // ... further stuff, e.g. `withCredentials: true`
    });
    this.http.defaults.headers.common['Accept'] = 'application/json;charset=UTF-8';
    this.http.defaults.headers.common['Content-Type'] = 'application/json;charset=UTF-8';
  }


  protected createParams(record: Record<string, any>): URLSearchParams {
    const params: URLSearchParams = new URLSearchParams();
    for (const key in record) {
      if (Object.prototype.hasOwnProperty.call(record, key)) {
        const value: any = record[key];
        if (value !== null && value !== undefined) {
          params.append(key, value);
        } else {
          console.debug(`Param key '${key}' was null or undefined and will be ignored`);
        }
      }
    }
    return params;
  }

  protected handleResponse<T>(response: AxiosResponse<T>): T {
    return response.data;
  }

  protected handleError(error: unknown): never {
    if (error instanceof Error) {
      if (isAxiosError(error)) {
        if (error.response) {
          console.log(error.response.data);
          console.log(error.response.status);
          console.log(error.response.headers);
          throw error;
        } else if (error.request) {
          // The request was made but no response was received
          // `error.request` is an instance of XMLHttpRequest in the browser
          console.log(error.request);
          throw new Error(error as any);
        }
      } else {
        // Something happened in setting up the request that triggered an Error
        console.log('Error', error.message);
        throw new Error(error.message);
      }
    }
    throw new Error(error as any);
  }
}

Feel free to modify the constructor to your own needs.

Creating a Concrete Service

Now we have e.g. a JobApiService like so

import type { JobCreateModel, JobModel } from '@/shared/models/JobModel';
import { AbstractApiService } from './AbstractApiService';

class JobApiService extends AbstractApiService {
  public constructor() {
    super('/api/jobs');
  }

  public jobs(customer?: string, portal?: string): Promise<JobModel[]> {
    return this.http
      .get('', {
        params: {
          customer,
          portal
        }
      })
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public job(id: number): Promise<JobModel> {
    return this.http.get(`/${id}`)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public startJob(job: JobCreateModel): Promise<void> {
    return this.http.post('', job)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public rerunJob(id: number): Promise<void> {
    return this.http.post(`/rerun/${id}`)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }
}

export const jobApiService: JobApiService = new JobApiService();

Note that we especially don't export the class itself! But we create an instance that can be reused/imported in other views.

const jobs = await jobApiService.jobs(customer, portal);

Further Extension for the Real World

A Service Cacher

My services request different domains (e.g. customer1.test.mydomain.com and customer2.prod.mydomain.com) or endpoints (e.g. /api/lang/en/groups and /api/lang/de/groups). But I kinda want to use singletons, so we fake the instances for the services and create them only once when they get first invoked.

So we build a ServiceCacher in src/services/ServiceCacher.ts

import { AbstractApiService } from './AbstractApiService';

export class ServiceCacher<Service extends AbstractApiService> {
  private readonly CACHE: Map<string, Service> = new Map<string, Service>();

  public constructor(
    private readonly serviceName: string,
    private readonly serviceClass: new (baseUrl: string) => Service
  ) {}

  public instance(baseUrl: string): Service {
    if (this.CACHE.has(baseUrl)) {
      return this.CACHE.get(baseUrl)!;
    }

    console.debug(`Creating new instance of ${this.serviceName} for baseUrl '${baseUrl}'`);

    const instance: Service = new this.serviceClass(baseUrl);
    this.CACHE.set(baseUrl, instance);

    return instance;
  }
}

Creating a Specialized Service Using the Service Cacher

At first, we have a sub abstraction for an API that is deployed for different customers.

// src/services/lps/AbstractLpsApiService.ts
import { AbstractApiService } from '../AbstractApiService';

export abstract class AbstractLpsApiService extends AbstractApiService {
  protected constructor(path: string, lpsUrl: string) {
    super(path, lpsUrl);
  }
}

(lps = Landing Page Service)

// src/services/lps/SynonymGroupApiService.ts
import type { SynonymGroup } from '@/shared/models/entities/Synonym';
import type { Pageable, Sort } from '@/shared/requests/Pageable';
import type { Search } from '@/shared/requests/Search';
import type { Page } from '@/shared/responses/Page';
import { ServiceCacher } from '../ServiceCacher';
import { AbstractLpsApiService } from './LpsApiService';

export interface SynonymGroupFilter extends Search, Pageable, Sort {}

class SynonymGroupApiService extends AbstractLpsApiService {
  public constructor(lpsPortalUrl: string) {
    super('/synonym-groups', lpsPortalUrl);
  }

  public findAllPaged({ search }: SynonymGroupFilter = {}): Promise<Page<SynonymGroup>> {
    return this.http.get('', { params: { search } })
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public findById(id: number): Promise<SynonymGroup> {
    return this.http.get(`/${id}`)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public create(content: SynonymGroup): Promise<SynonymGroup> {
    return this.http.post('', content)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public update(id: number, content: SynonymGroup): Promise<SynonymGroup> {
    return this.http.put(`/${id}`, content)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }

  public delete(id: number): Promise<void> {
    return this.http.delete(`/${id}`)
      .then(this.handleResponse.bind(this))
      .catch(this.handleError.bind(this));
  }
}

const serviceCacher: ServiceCacher<SynonymGroupApiService> = new ServiceCacher<SynonymGroupApiService>(
  nameof<SynonymGroupApiService>(), // https://github.com/dsherret/ts-nameof
  SynonymGroupApiService
);

export function synonymGroupApiService(baseUrl: string): SynonymGroupApiService {
  return serviceCacher.instance(baseUrl);
}

So it's a little different here when we create the instance for the service.
We create a function (like a factory) that can be called to get the instance from the cache or the Service Cacher will create a new one for us.

Now it can be called like so:

await synonymGroupApiService(portalUrl).findAllPaged({ search: search.value });

Please feel free to tell me what you think about that and provide feedback.
If the blog article helped you in any way, please also feel free to tell me :)

This was my first written blog post in my life <3