I was able to track down the original developer of a .NET icalendar library that had been abandoned. (It wasn't easy.) It had ambiguous licensing and copyright associated with it, which made me leery of using it for production tasks. He gave me explicit written permission to rename, open source[0], and relicense under a permissive license[1]. He also relinquished the copyright. I've also published a nuget package under the new name, Ical.Net[2]. The trouble is that if you look at the download stats, the older, buggy, under-performing library has many tens of thousands of downloads. It has a gravity to it that my library doesn't. How do I close the gap, and give people confidence that it's safe (and preferable) to use my library instead?<p>* It's unencumbered by licensing and copyright issues.<p>* It performs significantly better. The test suite completed in 17 sec; the current nuget package completes in 4.5, and I have an unpublished version that brings it down to 3.6. Performance was my original motivator for working on the library.<p>* I fixed about a half-dozen bugs while working on the performance<p>My plan of attack is as follows:<p>1) See if I can get the person who imported the original sourceforge history to commit a deletion of the code, and redirect people to ical.net via the readme.<p>2) Contact the original publisher of the unofficial nuget package, and ask them to unpublish it.<p>3) Have better API documentation. That's one thing the old package clearly does NOT have.<p>4) Maybe do a "Tell HN: dday.ical is now ical.net"(?)<p>What else should I consider? What else would you do? What would you NOT do? It seems to me that so long as the old code is floating around, and has a significant following, people are going to use that one instead. (I know I would as a naive outsider.)<p>[0] https://github.com/rianjs/ical.net<p>[1] https://github.com/rianjs/ical.net/blob/master/license.md<p>[2] https://www.nuget.org/packages/Ical.Net/
Looks like you have done a lot of good work!<p>I don't know about .Net, but in python-land there were three or four different oauth libraries floating around in various state of abandonedness. I guess they started out in the same way as you, by someone forking a project, working on it for a bit and then losing interest, whereby someone else comes along and creates yet another fork of the same project. For users (like me) that situation is very frustrating because there is no way you can choose the right oath project to use.<p>If I where you and I where <i>serious</i> about maintaining the project I would eradicate all impostors like a jealous God. Ensure that there are no download links to the old project, that it can't be NuGet:ed and that no other pages points to it. If people on Stack Overflow asks about .Net iCalendar, answer and recommend them your library. Add comments to answers pointing to the old library saying that it is abandoned and yours should be used instead.<p>It's a huge amount of work (see f.e <a href="https://github.com/search?utf8=%E2%9C%93&q=dday.ical" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=dday.ical</a>) which is one of the reasons I don't like maintaining packages.
Good documentation is key. It will be your main marketing vehicle. Study good online docs and copy their formats. You will start seeing patterns. They help with navigating and answering questions quickly. Leverage that. You could also have a workshop recorded and play it as a webinar. Good luck! :)<p>PS. Email me if you want feedback once you get going.