The main purpose of Hex is still to provide a public and free repository of packages. Companies were asking for a way to host their private packages on Hex.pm and I saw this as way to pay for the costs in running the public repository.
I don’t see a reason for why we should forbid anyone to sell packages they host on Hex.pm, in fact I’m not even sure that would be legal. Remember that this is also possible to do with GitHub or any other service that lets you host code. I haven’t heard anything about the open-source community being negatively affected because GitHub has a service for hosting private code, so I don’t think the Hex ecosystem would be negatively affected either.
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).
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.
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.
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.
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 ^.^;
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’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.
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.
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
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?
If we are going in this direction, then we should have it as: bitcask@postbasho, since it is a valid atom today and it won’t need special quoting:
{:bitcask@postbasho, "3.0.0"}
All Hex SCM needs to do is to check the name for a @ and automatically inflect the app name to be whatever is on the left side of @ and the organization to be whatever is on the right.
I have never been a big fan of namespaces and I have already voiced my concerns for them earlier in this thread, so I just want to make it clear that I am still not sure if we should add them.
I like that syntax .
The idea was to not make this part of organizations because it would require a lot more work on the backend and you would have to add the organizations with mix hex.organization first which would probably be annoying. I was thinking it should just be a different name in the global repository. This means that namespaced packages and private packages in an organization are different in usage and how you declare them but that may not be a bad thing since it makes it very clear what is public and private.
Hey @ericmj - could you please comment on the measures taken to ensure the privacy and security of packages scoped to an organization? I’m trying to assess whether organizations are a viable option for my security needs.
Thanks for all the great work on Hex.pm and on the organizations functionality. These are hugely valuable contributions to the Elixir community.
This is a very broad question so I will give a general description of some of our infrastructure, how we authenticate access, and store private information. Some if this applies in general to all of hex.pm and some of it is specific to private packages.
All communication to the hex.pm API and repository happens over HTTPS. When a user authenticates a new machine with mix hex.user auth we generate three keys:
A repository key used to authenticate against the repository when fetching private packages
An API key for performing read-only actions on the API
An API key encrypted with your passphrase for performing write actions on the API (for example publishing a new package)
All keys use HMAC, which means we never store your user secret.
Packages are stored on a private Amazon S3 bucket and we use Fastly as CDN to access the bucket. Based on the URL of the request to the repository we determine if the package requires authenticated access, if it does the CDN edge node makes a “preflight request” to the hex.pm API to verify the repository key against our database. Only if it succeeds do we continue with the request to the S3 bucket.
Our API servers run on Google Cloud servers and our database uses Google Cloud SQL with at rest encryption.
As I said this is a broad question so if you can elaborate on your security needs or if you have more specific questions you will probably get better answers. If you have any questions you cannot share in public please contact us on support@hex.pm.
All the code around organizations and private packages is open source so if you want to review the security the best thing may be to look at the sources themselves: https://github.com/hexpm/hexpm.
Thanks @ericmj for the prompt and thorough response. I had only briefly reviewed the hex codebase and while I had seen the Fastly CDN and various mirrors, I wasn’t aware of the multi-key authentication process. It’s extremely helpful to have this high-ish level overview of auth and data flow into and out of Hex.pm. I do have some addiitonal questions about controls for wiping data and packages that have been published to organizations, but I’ll forward these to the support@hex.pm. Thanks again for your support here and all of your great contributions to the Elixir community.
hex.pm and open-source
.
.
