Frequently Asked Question (FAQ)

This is a list of frequently asked question you might have regarding PayDevs. These answers may help you to understand the idea behind PayDevs and how we work.

If you can't find the answer to your question, please contact our support via, contact us on our Discord Server, or follow and contact us via a social networks accounts.

Maintainer-related Questions

How much does it cost me?

Nothing. For maintainers of open source libraries PayDevs is without cost. Only private and corporate users have to pay for access.

What do I have to do to switch to PayDevs?

To join PayDevs and 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. If we count users of your library, we will use the payout mechanism you specified to trigger the payout.

How can I switch from the open-source registry (e.g., to PayDevs?

In order to switch to PayDevs you only have to publish to our registry - however, there are several variants of how you handle the old versions on the public registry. For example, you can do the following:

  1. Soft Switch: You publish a new minor version (e.g., 1.2.x) exclusively on PayDevs. Then you can decide if you want to make:
    • Bug fixes available to the public: You still maintain the "old" versions on the public repository and fix bugs but don't add new features.
    • No public maintenance anymore: You completely stop publishing to the public registry and all new features and bug fixes are exclusively on PayDevs.
  2. Fork premium lib: You create a new major version (e.g., 2.x) with additional features or quality aspects such as better security, performance, more docu, more convenient methods, etc. and publish it exclusively on PayDevs. Then you can decide if you want to make:
    • Development and maintenance of the "old" public library goes on (without adding the features in the "new" premium lib).
    • Deprecate "old" library: You deprecate the "old" lib and handle it's maintenance like in the "Soft Switch" above.
  3. Delayed public publishing: Development and maintenance of the public library goes on, but you publish on PayDevs first and put it on the public registry after several months (e.g., 6 month later)

How can I inform my users about the switch to PayDevs?

If you don't publish a new version to the public registry your users probably won't notice that a new version was published elsewhere. To inform your users you can use:

  1. Smooth Paths: Easy and polite ways to inform your users are (especially, if done several weeks beforehand):
    • 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.
    • You can add the new location to your file - it will be shown to readers of your GitHub page and, if you publish this version to, to people viewing the page on
    • Special Version Number: Using the Semantic Versioning rules you can add a comment to the (last) version on such as 1.2.0-GO-PAYDEVS or 1.2.0-LAST-FREE-PACKAGE.
    • Deprecate methods (esp. for Java): Publish a last version that deprecates some or all methods - this will inform Users in their IDE when the get warnings about deprecated methods. A alternative or new version on PayDevs can then act as a drop-in.
  2. Uncomfortable Paths: These are more noticable techniques, that are more uncomfortable for your users and might cause a little outcry:
    • Breaking the build: You publish a "goodbye version" that is non-functional or otherwise breaks the build process (and thereby notifies your users about the new Status Quo). Your Users then have to freeze the last working version number once or switch.
    • Public Beta, Hidden Master: You publish "beta" versions on the public registry (e.g., "1.2.2-beta") but the final master (e.g., "1.2.2") is only published on PayDevs. You users might see the beta versions and wonder where the masters are - and then either have to work with the betas or switch to PayDevs.
  3. Aggravating Paths: These techniques are highly interfering, extremly uncomfortable for your users, and will probably cause a shitstorm:
    • Interrupting versions: You still publish to the public registry but every second (or random) version is non-functional / breaks the user's build process. Similar to "Breaking the build" your Users then have to freeze one working version and re-evaluate from time to time.

Payout-related Questions

As a maintainer who receives payouts from PayDevs you have to be aware of several factors. Most importantly, as with all income, you must declare it in your tax application and pay taxes on it.

When do I have to payout my money from a account in Stripe (or PayPal)?

For payouts via Stripe Connect you can "store" your funds for up to 90 days. Then you have to transfer the funds to your connected bank account, credit card, etc. More information can be found in the Stripe Connected Account Agreement.

What taxes do I have to pay?

The maintainer is responsible for paying taxes on the payouts from PayDevs in the country in which the maintainer resides or is subject to taxation. If you register a company as receiver of the funds, the payout includes the VAT and stated in an invoice.

User-related Questions

What do I have to do to access libraries on PayDevs?

To join PayDevs and participate in the payouts, you just need to register as a private or corporate user on our website, pay for the access, and connect to our registry.

Basic Questions

What is a Registry?

A registry is a database of built packages (or compiled binaries), each consisting of software and metadata. Open source developers use a registry to distribute packages of their open source projects to their users and download packages for use in their own projects.

What is a Maintainer?

A maintainer of an open-source project is responsible for the open source project's development, maintenance, and coordination of contributions from other commiters. Big open-source projects can have multiple co-maintainers sharing the responsibility and work.