
Ask HN: Best strategy to make an alternative to an existing open-source library? - tresne
An open-source library, which I use regularly, has limitations because it is designed for use with Arduino and other microcontrollers. However, the library (let&#x27;s call it &quot;ArduinoLib&quot;) can be compiled for desktop PCs, and I am among a few people using it this way.<p>To fix these limitations, I would like to write an alternative library for use on desktops. This would be a separate open-source project, using a different name. However, ArduinoLib is MIT-licensed, so there is the option to re-use some of its code.<p>Perhaps 1&#x2F;3 of ArduinoLib&#x27;s code could be used unchanged. Another 1&#x2F;3 would require major changes to add my desktop-focused enhancements. The final 1&#x2F;3 is microcontroller-focused and would not be useful for a desktop library.<p>I see several possible ways to approach this project, some starting with the existing ArduinoLib and some starting afresh:<p><i>1.1</i>. Fork ArduinoLib on GitHub, remove the microcontroller-focused code, then add my enhancements to this fork.<p><i>1.2</i>. As above, but instead of a true fork, create a new repository and begin by importing the latest version of ArduinoLib.<p><i>2.1</i>. Start my library from scratch, importing individual functions and&#x2F;or files from ArduinoLib where appropriate.<p><i>2.2</i>. Write the entire alternative library myself, only using ArduinoLib for reference.<p>The argument in favour of the <i>1.x</i> options is that they will lead to a project structure which is similar to ArduinoLib, whereas <i>2.x</i> will result in more differences between the projects. Such similarities should make it easier to share code between ArduinoLib and my library, which would be beneficial for both projects.<p>On the other hand, with the <i>2.x</i> options my library can start from a clean slate. I would be able to make my enhancements without any &quot;baggage&quot; from the unused microcontroller support getting in the way.<p>Which of these four approaches would you recommend taking? In what situations would you recommend one approach over another?
======
cauterized
Have you spoken with the project's maintainers? Are they uninterested in
incorporating your proposed changes? Because contributing back to the original
library could also be an option. Then you'd have the benefit of an existing
community to help with maintenance, documentation, etc.

------
tresne
Also, as I understand it, the fundamental difference between _1.1_ and _1.2_
is that a true fork retains the history of the original project. Is this
appropriate for a new project which takes an existing, active open-source
project in a different direction?

~~~
dozzie
The difference between 1.1 and 1.2 is very, very superficial. I couldn't care
less if a project has some GitHub-specific marker or not, especially that I've
seen several code hosting places come and go already.

On a second thought, this GitHub-specific marker of being a fork is somewhat
important. I skip forks, going to their original. Fork on GitHub usually means
that somebody either bookmarked the project or wanted to make some small
changes and possibly send them back to the upstream -- at least that's how I
perceive fork markers on GitHub.

