Maintainer Introduction

Table of contents

  1. How does PayDevs work?
  2. What do I need to do?
    1. How, when, and what to upload?
    2. How to inform my users?
  3. What Income can I expect
  4. What should I do next?
  5. PayDevs Roadmap

Maintaining and developing an open-source software library is fun and it can be fulfilling to solve a problem that you have. In the beginning, it's just you, the problem, and the code. Finding other developers who use and praise your project can be exciting - especially, when they start contributing code, tests, or docs.

Stressed woman before a laptop

After a while, however, library maintenance and development can become tedious - users want more and more features, bugs are harder and harder to fix, and enterprise users may even demand certifications to improve their SLAs. Doing this alongside a full-time job in your spare time and without pay is demotivating and discouraging.

Before OSS maintainers abandon their projects or suffer a burnout (see OSS incidents), a solution must be found. Solutions may include finding more volunteers and sharing the workload, being hired by a company to work exclusively on the OSS project, or monetizing the software and working on it full time.

Sadly, today's monetization approaches aren't enough to earn a salary - donations are unstable and often too low (esp. in a recession), dual licensing requires more non-coding work such as invoicing and opens liability questions, and most others involve additional work in the form of additional content, communication efforts, additional services, or creating an entire startup.

How does PayDevs work?

One Dollar Bill Our goal is to solve this problem by collecting money from every programmer who uses your open source library - a flat rate of $1 per month for private users and more for corporate users. We provide and operate a network of closed registries for your packages and handle the monetization as a service - without any cost for you!

To keep things fair and simple, we use a "money pool" where all payments are pooled and distributed monthly based on the number of users (i.e. not downloads) you have. In order to build a sustainable business and fund the servers and our staff, we take a portion of the payments - just like Apple, TikTok, or YouTube. In general, it works like Spotify or Netflix (where the user pays once to access all media), GEMA / ASCAP / PRS, etc. (where the player pays when he plays music for others), or some kind of tax.

The advantage for you is that we take care of the registry technology, payment and payout systems, user and corporate billing, corporate taxes, etc. - without any work or obligation on your part!

What do I need to do?

Joining and using PayDevs is very simple. To participate in the payouts, you just need to register as a maintainer on our website, upload a new version of your package to our registry, and inform your users about the new location.

Please note: Currently, only a NPM registry is supported and you must have created an OSS package on npmjs.com before March 2022.

After registering, you just need to run the following commands

npm set registry https://npm.paydevs.com/ 
npm login 

and/or maybe change the config for publishConfig.registry in your package.json file:

...
"publishConfig": {
  "registry": "https://npm.paydevs.com/"
},

How, when, and what to upload?

When you upload a new version to Paydevs, you can use different strategies:

  • Dual-publish: You publish your new version on registry.npmjs.org and npm.paydevs.com at the same time. Please note that the incentive for users to pay on PayDevs will be completely voluntary and we are unlikely to measure many users of your package.
  • Delay-publish: You release first on npm.paydevs.com and a few days, weeks, or months later on the public registry.npmjs.org. Early adopters have an incentive to pay on PayDevs and your broader user base has to wait until the version is published on registry.npmjs.org.
  • Beta-publish: You only publish "beta" versions on the public registry (e.g., "1.2.2-beta") but the final master (e.g., "1.2.2") is exclusively published on PayDevs. Your users might wonder where the masters are and maybe switch. Users not dependent on flawless libraries might work with the public version while users looking for more quality might switch and increase your payout.
  • Nofix-publish: You only publish major and minor versions on the public registry (e.g., "1.2.0") but all patches and bugfixes (e.g., "1.2.2") are exclusively published on PayDevs. Your users might wonder where the patches are and maybe switch. Users not dependent on flawless libraries might work with the public version while users looking for more quality might switch and increase your payout.
  • Dual-License-publish: You publish an (A)GPL licensed version on the public registry (e.g., "1.2.2-AGPL") and a MIT/Apache licensed version exclusively on PayDevs (e.g., "1.2.2-MIT"). Your users might wonder if there is a non-GPL version and might subscribe to PayDevs in order to get the non-GPL version. Users with a commercial application would need to pay via PayDevs without much additional work for you.
  • Exclusive-publish: You publish your new versions exclusively on PayDevs and stop publishing on registry.npmjs.org. This will result in a maximum number of users who will convert and that we will measure - thus maximizing your payout.
  • Split-publish: You create a new branch or major version (e.g., v2.0) with additional features and publish it on PayDevs. This basically represents an OpenCore model and might convert users wanting the new version and features.

How to inform my users?

In order to get noticed by your users - who are probably only looking for new versions on registry.npmjs.org - you need to inform your users about the new versions on PayDevs. For this, you can use the following techniques and inform them via:

  • Social Media: Post the new location on Twitter, Reddit, etc., or your community platform (e.g., Discord, Slack, etc.) perhaps along with an explanation of why you switched.
  • Readme.md: You can add the new location to your Readme.md file - it will be shown to readers of your GitHub page and, if you publish this version to registry.npmjs.org, to people viewing the page on npmjs.org.
  • Special Version Number: Using the Semantic Versioning rules you can add a comment to the (last) version on npmjs.org such as 1.2.0-GO-PAYDEVS or 1.2.0-LAST-FREE-PACKAGE.

What income can I expect?

Accurately calculating your projected revenue is complex and depends on the number of users you have and that we can measure in PayDevs, the number of maintainers on PayDevs who participate in the payout, and the number of private and corporate users who have paid for access. The payout will be calculated using the following formular:

Payout ≈ UU * (PU * (1$ + 100$ * CP) / UD)

Calculator

where:

  • UU: Your Unique Users (max: #Users)
  • PU: Number of all Paying Users
  • CP: Corporate Percentage (i.e., how many corporate users vs private users)
  • UD: Unique User Dependencies (max: #User * #Packages)

To give some examples lets look at several variants and assume that on average each maintainer (except for you) has 1k users and only 10% of users buy a corporate account (via their employer):

  1. You have 1k unique users (UU), 10k users in total are paying on Paydevs, and 99 other maintainers with 1k unique users are registered on PayDevs (UD = 1k * (1+99) = 100k). The Money Pool would be filled with 110k USD distributed equally over 100 maintainers - resulting in approx. 1.1k USD per month.
  2. You have 10k unique users (UU), 100k users, and 99 other maintainers with 1k unique users are on PayDevs (UD = 10k * (1+99) = 1M). The Money Pool would be 1.1M USD distributed equally over 100 maintainers - resulting in approx. 11k USD per month.
  3. You have 100k unique users (UU), 1M users, and 999 other maintainers with 1k unique users are on PayDevs (UD = 10k * (1+999) = 10M). The Money Pool would be 11M USD distributed unequally where you receive 100k shares of 10M - resulting in approx. 110k USD per month.
  4. You have 100k unique users (UU), 10M users, and 99.999 other maintainers with 1k unique users are on PayDevs (UD = 10k * (1+99.999) = 1B). The Money Pool would be 110M USD distributed unequally where you receive 100k shares of 1B - resulting in approx. 110k USD per month.
No.Unique UsersPaying UsersMaintain.Mth. Payout
1.1k10k1001.1k $
2.10k100k1k11k $
3.100k1M10k110k $
4.100k10M100k110k $

Note: As of 2022, the max. number of JavaScript developers is assumed to be between 10 and 12 million, while the max. number of OSS maintainers in npmjs.org is 590k (incl. test project owners).

Register

Using PayDevs Registries

After registering you will have access to our NPM Registry and can use a command line package manager of your choice (e.g., npm, yarn, pnpm) to login and then download or publish packages (if you are the maintainer of the package on NPMjs.com).

To login you can use the following commands (more info is listed on the NPM Registry):

npm set registry https://npm.paydevs.com/ 
npm login 

Roadmap

Currently, we are planning on slowly rolling the system out and testing it more rigorously. This means that we will pass through two beta phases until we launch the full system. These phases are:

Rocket launching

  • The Private Beta will run during September and October 2022 and is only open to invited maintainers and users. No payments or payouts will be made - this phase is only meant to test the technical system. The benefit for participating maintainers is the participation in the next phase with real payouts.
  • The Public Beta will start in November 2022 and is only open to maintainers from the private beta. However, it will be public to users who then have to pay for the access to the registries. Payments will be live and automated while payouts will be done manually. The benefit for participating maintainers is to be first receivers of payouts with a small group of other maintainers.
  • The Launch will probably be at the start of 2023 and is open to all maintainers and users. Payments of users as well as payouts to maintainers will be live and automated.