I'm writing a library. It's a completely rewritten version of another one, to suit my needs (PCL compatibility, mainly). However, the API will be completely rewritten, as I'll need to change a lot of stuff around for PCL compliance. Also, as it is a rewrite, I won't be able to just start from the library and just change it bit by bit, as I typically see with forks. I tried that, but it just didn't work.

So what should I do? Should I fork here or should I make a new library?

  • Is it a real fork then or is it a new project with some ideas from another project? If that's the case (and you don't re-use code) then why not put a link in the documentation to the original project for example? – Luc Franken Sep 1 '13 at 10:52
  • @Luc I'm reusing some code (e.g. enum declarations) and rewriting all the rest from the source there. That's what I'm thinking but I'm not sure what the standard on this is. – It'sNotALie. Sep 1 '13 at 10:53
  • If that's the case it sounds like you use a real small percentage of the original project. If that is true I would suggest start totally from scratch so you can freely define everything including licensing etc. If it really saves time for you to work based on the original project maybe contact the original developer, maybe you get some help to make it PCI compliant. – Luc Franken Sep 1 '13 at 10:57
  • 1
    @It'sNotALie.: I guess there is some confusion here what you mean exactly by "forking". Are you talking about a model in your version control system? Or are you talking just of going back to the approach "change the old library bit-by-bit" (though you came to the conclusion that this does not work well in your case)? – Doc Brown Sep 1 '13 at 19:22
  • 1
    You're really dealing with a minor semantic issue - forking v. copying code. The main reasons to fork are to keep your revision history (not that important if you've done a major rewrite) and to let interested parties know that there's a relationship between the two projects. – Sean McSomething Sep 2 '13 at 0:05

"It's a completely rewritten version of another one [...]"

Strictly speaking, something completely rewritten isn't considered a version; at least not in computing where we take "version" somewhat formally. For example, it is misleading an incorrect to call Linux a "version of Unix". The word widely accepted for this is "clone".

Something rewritten also cannot possibly be a fork, even if it resembles the original to the point of being a clone (such as by having similar or identical interfaces).

Since you've tried modifying the original and it didn't work, and then embarked on a rewrite, that bridge has already been burned: the rewrite isn't a version, and so it cannot be considered a fork. It isn't even a clone, because the interfaces are different!

It's a new library which covers a similar area of functionality as the old.

If the library internals are complicated and worth reusing, and the new interfaces can be easily adapted, to use the existing internals, then a case can be made for extending the library: keep the old interfaces in place (perhaps providing a way to remove them at compile time to save space). If that approach was feasible for this library, then you wouldn't be doing a complete rewrite, though.


So what should I do? Should I fork here or should I make a new library?

With both options you'll be left working on some form of new iteration of your old project. The differences lie in other things:

  1. Forking would leave you to start working with the last version of the code of the previous iteration, so here it depends on how similar in structure / design you envision the new iteration in respect to the previous one. If it's too different, you might opt for starting a new library instead of forking.
  2. When you create a new project you are detaching yourself from the source code repository of your previous iteration. Forking would keep your projet in the same repository, enabling you to rollback to or get from a specific historial version. Advantages of not forking, from this aspect, would probably be better order and organization and less clutter of your new repository as you start fresh.
  3. If this is an open source community driven project, then you should consider forking or not also based on the fact that the decision will in itself convey content to the community. Forking would indicate the new iteration should be thought of in terms of being a direct continuation of the previous one. Starting a new separate project would indicate to the opposite.

Do you have tests? If so, how tightly are they bound to the code rather than the behaviour? I'd work through the tests if they work at the behaviour level.

If you don't have tests then (please) write some and use that to drive out what you need. It sounds like a rewrite, so apart from reusing ideas it might be better to say that it's a "major release number" and therefore a new version altogether.


Given that you are essentially re-writing everything from scratch, you should create a new project. Forking would imply that the two share enough similarities that sometime down the line, you could share features, take some new addition here or give some fix there. That's clearly not going to be the case.

Not the answer you're looking for? Browse other questions tagged or ask your own question.