First, a disclaimer…
I 
Julia lang. Personally, I am heavily invested in Julia and have been for the past 5 years. As an entrepreneur, that is not a small thing. I am also a Julia evangelist. I promote Julia any chance I get. I’m happy to do so and will continue to do so.
As much as I Julia, it doesn’t mean I am immune to unpleasant experiences, so I am sharing these thoughts with good intentions hoping to impact some positive change.
Noob
Despite my age and despite how long I have been a part of this community, in many respects, I still consider myself a “noob” when it comes to open source software.
For me, February was a rare and beautiful month. I was able to spend pretty much the entire month working on Julia open-source projects. That also gave me an opportunity to move up the learning curve a bit when it comes to open source generally.
Registering your first package
If you are like me, I was excited to register my first Julia package. I keep joking that we should gamify your Julia journey in which case registering your first package would definitely be “levelling up”. However, if you are a scientist, engineer, or financial “quant” (or anyone for that matter), it is a good idea to pause and think about what that means.
Registering a package is a one-way street
My unpeasant experience came about recently as I am trying to build up the JuliaFinance organization.There is one small package that is core to all others. Every JuliaFinance package will likely have a dependency on this package. For various reasons, I decided to create and maintain my own registry for JuliaFinance. The amazing new package management system makes this possible and when I read the docs the first time, I immediately had the idea to maintain my own registry some day so I took the plunge last month.
Since all my new packages are (and will likely be) registered on the JuliaFinance registry, but this one core package was registered on the General registry, it made since to me to move it from General registry to my own registry.
In hindsight, I can appreciate that most of the ensuing unpleasantness was due to my own ignorance about how open source and registries, in particular, are supposed to work.
Although I am pretty sure not a single person on this planet is using the package I wanted to remove from the General registry (and if there was, I’d be happy to personally work with them to fix things), the push back I got was shocking to me. I can understand the conservative position of the General registry maintainers, but this was not a highly popular package by any means. It seemed like a non-brainer to carry out my request.
So here is my warning to noobs (like me):
Before registering a package, make sure you understand the ramifications.
General registry Terms and Conditions
I’m sure many people remember this story:
The story actually rhymes somewhat with my experience. It started with wanting to rename a package. Then, during the unpleasant episode, at one point, I admit I considered a nuclear option of hiding the git-sha-tree so the General registry would be broken for my package and Pkg would find it on my registry instead. I don’t consider myself a rebel or a community destroyer by any means, but the fact that the thought even crossed my mind means there is a risk. What would someone else do in a similar situation?
The episode concluded when I agreed to park the discussion until the transition from METADATA is complete, but the subject will likely come up again since I am still interested in unpublishing it.
When I read npm’s “Unpublish Policy”, it helped me to understand the position of the General registry maintainers. Like I said, the unpleasantness stemmed mostly from my ignorance of how things are supposed to work.
Then again, why didn’t I understand how things are supposed to work?
I never agreed to a Terms & Conditions when I registered my package. There are no Terms of Use for General registry.
As we prepare to migrate from METADATA to General registry, I think a part of that process probably should be the introduction of a T&C explaining, among other things, the unpublish policy.
Personally, I would be very happy if, upon the introduction of the T&C, we were given the opportunity to “opt out” and unpublish - without penalty - an existing package if unpublishing would not have a major impact to the ecosystem in ways that can be quantified, e.g. number of other packages that depend on it, etc.
That way, if I choose not to unpublish or if I publish a new package in the future, the terms of doing so are clear. They were not clear to me and I suspect they are not clear to many other package developers (who may not be OSS experts) as well.
Note: I was warned that I could be non-whitelisted for registering any new packages in the future if I insisted to unpublish, but I feel that would be unnecessarily harsh given there were no T&Cs - at least none that I was aware of - in first place.
Thought on an Unpublish Policy
npm’s unpublish policy is localized in time, i.e. you have a 72-hour window form the time you publish a package to unpublish. I hope the maintainers of General regstry might also consider localization in space, i.e. if a package is not a dependency for a large number of other packages, it can be unpublished. All this stuff could be clarified to help resolve the inevitable future disputes that will arise.
In any case, I am confident all of this stuff will be worked out in time 
