Monetization on hex.pm? Encouraging sustainable, high-quality contributions?

Chat / Discussions
,
1

Q: Are there any plans to expand hex.pm to help authors of packages capture some of the value they created?

Details: The creators and contributors to the Erlang and Elixir ecosystems have created amazing value, but capturing some of that value is not an easy task. An occasional package developer might take it on and build their one-off payment mechanisms (e.g. Oban Pro’s neat subscription machinery), while most others treat their open source contributions as after-work activities, “for exposure,” or for fun. These are great approaches, but they are also limited in terms of appeal and sustainability in a world where we need to pay our bills.

If the author of a package is able to capture some of the value they have created, it might be easier for them to justify dedicating their bandwidth to the package, over longer periods of time. This will likely lead to more high-quality, sustained contributions to the ecosystem.

If anyone can pull this off as an actual positive-sum solution, and an actual Pareto improvement – rather than another example of the Tragedy of the Commons, killing something amazing by privatizing its value – it’s the Elixir team. ; )

Here is one way this might look like:

  1. As a developer, I can use my hex.pm account to “buy” or otherwise contribute to packages I use or otherwise want to support. My hex.pm account comes with a build key that I use in my mix.exs when fetching my dependencies. mix deps.get performs validation of packages’ policy.

  2. As a package author, I can attach a pricing structure to future versions of my package (e.g. “free”, “free for _” / “paid for __”, “paid”, “one-time payment”, “subscription”, “free but appreciate contributions”, “free, with a build-time message”).

  3. hex.pm provides: account/build key management, payments/distribution, and mix deps.get / mix deps.update verifications. hexpm can also provide a bit of curation, reducing the likelihood of fraudulent packages (perhaps contributing to Elixir’s OpenChain initiative). This handling comes with a fee that supports hexpm’s own sustainability and operations (but without the profit-maximization motive).

(This is just an initial draft of possible behavior.)

Helping package authors capture some of the value they have created for the community seems to have a big upside for the community, but, clearly, this is also a non-trivial project to get right. I am wondering what folks here think about this.

I am very interested in your thoughts.

2 Likes
2

I think this has always been much more of a social, policy and financial problem than a technical one.

IMO your idea is great. I love it. But the words “capturing value” are exactly both the solution and the problem. It really depends on what library we are talking about. Oban Pro? Unquestionably great choice because trying to roll your own is a project, to put it mildly. But f.ex. a GPS-to-MGRS (and vice versa) conversion library? Meh. Almost everyone can write that from scratch in a weekend.

“Capturing value” is basically, I think in this case, saying “please give back a little because you are taking so much for free; some appreciation, hello?” – and I don’t think it will work. People just love getting stuff for free and will only pay if they don’t have a choice (again Oban Pro; try replicating it yourself!).

So yeah. “Capture the value” indeed.

So my thoughts here are, except for my well-founded cynicism, is that your idea would likely morph into “let’s try to provide some sponsorship to high-value and very popular but free libraries in the ecosystem”. I think that would be the much better and realistic aim. Though then your next order of business is identifying those…

3 Likes