33

I want to fork on Github the TestNG java testing framework (Apache 2 license) so I can add/change some minor things to suit my needs.

It's unlikely that all of my changes would be approved in the main project or that other people would use my fork. This would in no way be a competition to the main project.

Now, in terms of naming, I want to change the artifact name (testng-mycompany) or the version (6.8.mycompany) so there's no confusion with the official version in my maven repository. Would this be considered poor etiquette? If yes, what is the best approach to distinguish your fork?

Bogdan Calmac
  • 431
  • 1
  • 4
  • 5
  • 9
    See also [Forking project on Github process](http://programmers.stackexchange.com/questions/153467/forking-project-on-github-process) and the [etiquette and forking tag intersection](http://programmers.stackexchange.com/questions/tagged/etiquette+forking) (which currently has your question and the linked one). –  Feb 26 '13 at 18:18
  • it would be cool if the package ended in `ork` numpy --> numpork, pandas --> pandork – Kermit Aug 25 '22 at 15:38

2 Answers2

8

Fork away and do your worst / best.

Open source software has always been about letting individuals adapt, change and challenge convention. The hard part about forking a project is developing a new community around you that believes in what you are doing.

For example I could download the source for Apache, make a few modifications and call it the next big thing.. but if no one else gets on-board then I'm stuck playing catchup to the zillions of new features and bug fixes provided by the core Apache community.

Reference : Game of Thrones.

Rather than fork TestNG it might be simpler to write modules / add-on for it on top of the existing Repo, that way you will only need to maintain your own code.

Alternatively if you feel the need to alter TestNG then perhaps it's simply the wrong tool for the job.

[ Disclaimer, I've never heard of TestNG till now ]

dave.zap
  • 569
  • 2
  • 6
3

Open Source projects are intended to be advanced. The great thing about open source projects is that they encourage outside collaboration. When you decide to fork a project you simply state that you have taken the initiative to produce your own "flavor" or "interpretation" of the project. Many teams will end up forking their own projects in order to expand the base of the project for multiple purposes.

Example: Webkit and Blink

As far as naming goes, you want to be as clear as possible. Basic nomenclature practices in development are rather ambiguous.

Go To: What "version naming convention" do you use?

If you were to fork you would want to state your "Name" and then convey exactly what version you are using.

I do not see a reason to fork unless you plan on taking the project in a fundamentally different direction than what was intended. I have found that, in most cases, the added features/modifications that I would propose offered a great learning opportunity from both directions. If anything I am with Dave on the idea of creating separate modules in order to promote modularity while preserving the integrity of the core project.

Community
  • 1
Colt Stumpf
  • 31
  • 2