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.

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?

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 make monthly payouts 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 - just with software libraries.

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.

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/"
},

Please note: Currently, only the NPM registry is supported and you must have created an OSS package on npmjs.com. We sync with the public registry on a weekly basis.

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 our registry (npm.paydevs.com) and a few days, weeks, or months later on the public registry (e.g., 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 the public registry.
• 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 a little complex and depends on a) the number of users you have (and that we can measure in PayDevs) and b) the number of libraries each user uses besides yours. The payout for one specific month will be calculated using the following formular:

where:

• U: Your Users: All users who have downloaded your library at least once in the month for which the payout is calculated.
• P: User's Payment: The amount of money a user paid per month excluding taxes as well as fees of payment providers and PayDevs.
• D: User's Dependencies: The number of dependencies (to libraries) a user used in that month with a registered maintainer in PayDevs.

To give some examples, let's look at different variations and assume that a) 10% of your userbase are corporate users who pay for a corporate account (through their employer) and b) 100% of maintainers of all dependencies are registered with PayDevs.

The following table starts with an example where we calculate with 1k users (U), of which 100 are corporate and 900 are private, resulting in an average pay per users of ~$11 per month (P_AVG). If each user (on average) has 100 dependencies (D_AVG), you would receive 1/100th of each user's payment or 11ct per user - resulting in ~110 USD per month.

Note 1: How many users do you have? Since we don't have hard data at this time, we can try an approximation. If each user has a CI/CD pipeline and builds their system every hour (8 times per day), your package would be downloaded ~250 times per month or ~50 times per week. This lower bound would indicate that a package with 500k downloads per week would have about 10k users.

Note 2: In the beginning of PayDevs several factors will influence the calculations further: a) not all of your users will join and pay (lower "U": less money for you), b) companies will be reluctant and join late (lower P_AVG: less money for you), but also c) not all maintainers will join and get payouts (lower "D": more money for you), and finally, d) more than 10% of the companies might pay for accessing new versions of essential libraries (higher P_AVG: more money for you).

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:

• The Private Beta ran 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 Big Pause during November and December due to company formation and Payout Calculation refactoring (The initially planned "Moneypool" is not allowed by payment providers).
• The Public Beta started in January 2023 and is open to all maintainers and users with a live payment system.