OvermindDL1

OvermindDL1

Both of these instances were far in the past so hopefully things have changed now, and I have indeed seen closed things on Github actually get opened up rather than happen the other way (whoo), so I hope history does not repeat itself but it does still scare me considering the question asked. ^.^;

And yeah, I was never talking about hex getting paid at all, that is a great idea, I was purely talking about the software on hex eventually getting less open just because of other users choices, nothing about hex at all.

Have you thought of adding a patreon-like system? That would help fund both hex and the package authors both (which has elsewhere shown to increase the quality of packages substantially). :slight_smile:

0
Post #23
ericmj

ericmj OP

Elixir Core Team

I want to clarify also that we are not planning add a system to Hex for person A charging person B for access to A’s packages on Hex.pm.

If organizations are successful we won’t have to ask for donations hopefully. I would be happy to add something to Hex to promote donations to package authors but I don’t think Hex itself should handle this.

1
Post #24
OvermindDL1

OvermindDL1

Yep I meant to package authors (though like patreon hex itself could take a tiny percentage).

Perhaps a patreon widget (although I hate to special case for only one service when there are others) on a library page that shows the donation link and information (like showing the amount of people ongoing, the amount donated, etc…). Research has shown that just ‘seeing’ that information improves further donations so it would be helpful to many. :slight_smile:

1
Post #25
wojtekmach

wojtekmach

Hex Core Team

Perhaps a patreon widget (although I hate to special case for only one service when there are others)

Agreed, special casing one particular service is less than ideal. I’ve seen some OSS projects use Patreon badge in their project README on GitHub. We’re actually discussing rendering project’s README on hex.pm [1] but as you’ll see in the issue there are some serious security considerations. (We already allow rendering README on hexdocs.pm.) I’d guess people willing to support a project would visit it’s GitHub/GitLab/etc page anyway, so promoting it there should be the first step. For now, if someone wants to promote their Patreon page on Hex.pm the options are to mention that in package’s description and links.

[1] Display repository README on package landing page · Issue #560 · hexpm/hexpm · GitHub

0
Post #26
OvermindDL1

OvermindDL1

Yeah I agree about the arbitrary html, immediate thing I come up with for such a widget is pre-built ones (of which more could be added via a template in the repository as a PR or so?), but otherwise I had the same thoughts as that issue #560, hence why I did not recommend raw html./javascript ^.^;

0
Post #27
ryanwinchester

ryanwinchester

Wow, I really started something with my earlier question.

I see no issue with there being open source and paid software/libraries. I use, contribute to, and create both.

My question stems from the idea of, for example creating a CMS, if it were to ever get popular, you often see marketplaces for plugins. If there were a popular elixir CMS, plugins/extensions could easily be hex packages. Examples like, Wordpress, OctoberCMS, etc

and if you could programmatically add access tokens to a private hex package you could use it to sell access to certain premium packages/plugins/extensions. this would also be a way that hex could generate revenue for itself by charging a bit more for a plan that includes something like that (unless the current private plan would cover that)

Having a simple way to offer paid access to some things is not going to end open-source.

i :heart: hex.pm and open-source

0
Post #29
OvermindDL1

OvermindDL1

In the good communities perhaps, but every time I’ve seen it before it devolves rather quickly when it becomes first-class. ^.^;

I have hope for Elixir’s community though.

But still, Paid Support > Paid Code every time in my opinion.

0
Post #30
binarytemple

binarytemple

I’ve no interest in private package hosting (disclosure, Erlang Solutions Employee working on Riak). But what I do need is a namespace I can upload to so I don’t conflict with other users working on the same set of 20+ (soon to be) hex packages. I want everything to be public, and I don’t want to create merge conflicts by renaming - for example bitcask to postbasho-bitcask - that’s just ugly. Ideally I’d set an environment variable for the namespace and work from there. Any suggestions for my use case? I was thinking of running my own hex.pm but I want other people be able to run the same builds on their own computers without having to access a private hex.pm instance.

2
Post #31
OvermindDL1

OvermindDL1

NPM’s form of namespacing is very useful. You have primary named packages (like my bucklescript-tea library), but a user can also have their own packages, so I could also publish something like @overminddl1/bucklescript-tea. I cannot install the same named package from different users or global though, only one can be installed at a time, but it is fantastic for such collisions like that or forks or so. I’d love to see similar in hex.pm. :slight_smile:

0
Post #32
ericmj

ericmj OP

Elixir Core Team

I want to avoid namespaces because it can easily create a fork culture. We don’t want the situation that has existed in the Erlang community where people would fork a github project to do their quick fix and never merge it back into the upstream package, it would get even worse when the original project was abandoned and their would be 10 different, diverged forks to chose from. By using a single global namespace I think there is less chance for this situation to happen because there is only one true source for a given package.

You can also have different package and OTP application names so you name the package postbasho-bitcask without changing anything in the code. Or maybe we should just allow / and @ in package names and you can name it @postbasho/bitcask :slight_smile:

EDIT: Add in a restriction that only the postbasho user can create packages that start with the name @postbasho/ and we basically have namespaces, right?

3
Post #33