Long-term Nexus custodian here. Last year's licence rugpull by Sonatype had be thinking the same. I particularly loathe their new front page "malware" warning saying you have to contact them to find out what it is. Sure.

I've read the main readme so excuse if comments are covered already but key features and/or opportunities: - backend supporting Azure (Nexus has this under Pro though community does support S3 under community at least) - clear navigable S3 structure that could be sorted by a human if needed, like the on-disk backend of Nexus 2 used to have, not like Nexus' current organisation/obfuscation (which would be understandable but for...) - maintenance routines that actually work (Nexus' are a joke and very limited features for both cleanup and the task set leaving ever growing detritus). - having an automatically take the latest from upstreams is a big problem in the npm world; it would be a perfect fit to introduce this kind of staging concepts and window on upstream (proxied) repos - needs restful APIs and deep links to artifacts for ease of integration - we end up proxying other sources of files in a web proxy since there's no easy "pass through" via Nexus where we don't want to copy the current files into our DB or S3 but just want to pass the latest to the consumer. a direct proxy feature with URL remapping would be cool

Things I'd have to play around to understand what it does currently: - whether it has proper proxy and group support; composition is completely essential - whether that caching is sensible there (Nexus does a poor job, though it's a hard problem, when bad states get cached) - efficient (Maven) metadata generation (Nexus is abysmally slow) - whether rbac is clear over the repo structures (Nexus does ok here except everything is repo level AND the initial setup is very painful). - P2 consumption looks to be a supported format but P2 hosting I think was nerfed after Nexus v2.11 and some clients still use that - rpms added ("yum" to Nexus) but as with repo hierarchies would need to be assured they can be nested and will correctly produced merged repomd.xml and the like so they function properly

other comments: - having the security scanning in an open source tool would be amazing - it would be very hard to get clients to trust this without either a community and review process or a company (that "can be sued") behind it. I know it's very early days but it's a bit chicken and egg as if I can't use this on clients I wouldn't use for anything. Not that I am a valuable customer by myself, but I influence clients decisions who then need that support

My graduate research focused on common computer security misconceptions — one of the biggest being that open source is inherently insecure. The reality is the opposite. The algorithms and systems we trust most are the ones that have been open to public scrutiny. AES was selected through an open competition where every candidate was published for the world to attack. TLS, SHA-256, RSA — none of these are secret.

Their security comes from transparency and years of public audit, not obscurity. The same principle applies to software. I see the legal argument for wanting a vendor to sue, and I've thought about something like Canonical's model for Ubuntu — offering paid support around a free product. But I don't have years of production use behind this yet. We all start somewhere. So for now, this stays open and free for everyone to use, and for me and others to maintain.