We are announcing the addition of private packages on Hex.pm. With private packages you can publish packages to Hex.pm that only your organization members can access and download. With your organization you get a repository namespace on Hex.pm so that your private packages will not conflict with packages in the global, public repository. Go check out the documentation https://hex.pm/docs/private to learn exactly how it works and go the sign up form https://hex.pm/dashboard/signup to request access to the beta.
I totally agree with that idea. I hope I will manage to persuade my boss to use it. I thought about it for a long time, because it’s way much better than using private GitHub repos.
We can’t wait to use it at wooga. And perfect timing. We nearly configured our own hex.pm instance. Looking forward to try it out. Way more convenient than hosting our own
The pricing is not decided yet but it will be free to use while we are in beta which is expected to run for a few months. The price will be based on the costs of running the new infrastructure required to support private packages and the interest in the service during the beta. We will have a pricing model similar to NPM and GitHub where there is monthly fee based on the number of members in your organization.
Open source projects and organizations can use the service for free, but keep in mind that packages will only be visible to members of the organization.
That’s perfect. Will it have hexdocs.pm integration at some point too? I think that’d be killer feature for me, making it very much preferred over private GH repos.
Yes, that’s what we are working on right now. Hexdocs requires more work since it needs to change from static file hosting to a server with authentication and needs subdomain isolation between organizations so that cookies cannot be stolen or XSS attacks performed.
Hi! Living with an unreliable internet connection, I was wondering when we would have support for multiple hex sources. I think the subject has been mentioned a couple of times on IRC, but I’d like to know if it’s actually planned to enable that.
As far as I know, Hex already provides mirrors via fast.ly and allows you to set your own mirrors and even change the HEX_API endpoint.
If you mean literally multiple sources, with packages coming from different places, then that’s exactly what the private organizations feature provide. When you specify {:foo, organization: "foobar"} that’s a shortcut for {:foo, repo: "hexpm:foobar"} and that repository can be anything, including something that you host on your own and is not part of Hex.
I’m of the general opinion that Work should be paid for, not Products. Patreon is a good example of this. Like I could see Hex being a service that allows people to donate to certain/multiple authors if the authors accept donations either once or on-going, these tend to work quite well in my prior experience, but when software starts get locked behind walls I’ve seen and experienced communities that stop growing at best and die at worst thereafter. Every-single-time I’ve experienced an open source community starting to lock software behind money then that is eventually what it all becomes about as those that go for money instead of advancement start pushing (in some personal experiences very forcefully) the open source authors out and as I’ve experienced that multiple times in the past (in two cases very very personally) it is scaring the hell out of me…
EDIT: Don’t get me wrong, organizations are a great idea (we can have identically named packages in different organizations would be an awesome feature!), and packages should have a private status (great for locking out old/broken packages and handling ‘in-dev’ packages that are not suitable for public consumption), but it is a great basis to lock out the ecosystem if not careful, and I know that not only can it be done but I’ve seen it done multiple times in the past…
@OvermindDL1 The dangers you outline highly depend on how will Hex creators handle it mid- and long-term. Private packages are only useful for organizational development teams since it’s very costly in terms of both money and development hours to roll your own package repository. Nothing wrong in outsourcing that expense to Hex itself.
Additionally, many organizations would much prefer to refactor out useful / value-adding components as public and OSS packages, so not even all companies would use the private packages functionality.
The main motivation I see behind paid private packages are mostly because of the potential very long-term investment a company might make in Elixir; I needn’t remind anybody around here that there are still banks that hire COBOL consultants for $400 an hour to fix 25+ year old systems. In the same lane of thought, organizations might have 50+ private packages measuring tens or hundreds of megabytes big and they might use them for 20+ years as well.
Hosting costs money, we all know it. When it’s for the public good, many people choose to benefit the society for free and I commend them for that. However, when you have a big company like the above theoretical one, their servers might pull private packages tens or hundreds of times a day for their CI process. That would be a lot of load. If the load keeps growing without Hex having the budget to cover hosting expenses, then Hex won’t last long.
Lastly, companies like the idea of paying for a service and being rid of the responsibility to maintain the thing, plus it gives them the peace of mind that the service won’t just shut down next year.
That being said, CI processes pulling public/free packages from Hex thousands of times daily is also a reality and I don’t know how the maintainers handle it. Maybe making a federated network of copies of Hex is a good idea for the future; all mirrors except the main node will only ask for differences through IDs / checksums and will periodically suck the updated packages (or simply employ a normal CDN). That might help Hex’s free version remain free forever. But that’s long-term.
Oh no not at all, I did not get my thoughts over right! I’m all for hex offering extra options like that (heck, I could host hex’s hosting in full with little hit on my servers), what scares me is the average library starting to be behind a paywall, this is not a hex thing, this is a community and the people in it thing. Like I said I’m all for organizations and private repo’s sure, what I’m not for is for putting public (non-internal-corporation-etc…) libraries behind paywalls as a growing ‘standard’. The question by the other person above of basically asking how to put a paywall up in front of their library on the public package system (a token/license to access it) is a death-knell in multiple places I’ve been…
Don’t quote me on this, but historically the open-source community has been quite good in isolating the software authors who ask money from you if you sneeze.
The Elixir community is stable and the people who join it are believing converts (me included). There’s no way Hex isolates that community. Furthermore, I am convinced there are people in this forum who’d donate hard cash to Hex if it has trouble with its hosting expenses – and I am one of them.
As Jose said, it’s fully within the right of someone to sell their software – I’d go a different way, like pre-packaging my app and signing it with the keys of the customer, but let’s not go off-topic.
I’d donate hosting to them in a heartbeat (my actual money is… low… very low…). ^.^
And I have no issue with someone selling their software in the usual areas where things are sold (their website, amazon, etc…), but not selling them via an open package repository. The only times I’ve seen that start to be allowed did not end well (in one case I was close in the entire ecosystem locked up, there is not an open source thing left, in the other case I was close in it became… loud, eventually the parent company who had no stakes in the open source parts had to very heavily handed shut down the ones trying to lock out what was happening behind paywalls, this one ended well but only because there was a very legal reason to not allow what they were doing).
