23

Suppose I'm working on a FLOSS project and someone forked it and the forked project seems to be moving faster than mine and gains more popularity than my original project (possibly because the people behind the fork have a bigger team).

I'm excited people are showing interest in my project, but feel discouraged because, as the original creator of the project, I play no part in the development of the most popular fork of the project now, since no decisions regarding changes made to the fork are run by me. The maintainers of the fork show little to no interest in cooperating/communicating with me.

Should I just abandon my fork and join theirs, if I want to stay relevant to the development of this project, or is there another option?

8
  • 7
    I don't think you should feel discouraged. It's perfectly normal for a project to change hands over time and you should be proud of your part in creating a healthy and thriving open source project. As for what you should do... do whatever you want. Go ahead and get involved in one or both projects. Hopefully they're not both exactly the same - a healthy fork will have slightly different goals to the original project (for example, WebKit and Blink are the same at surface but underneath have very different core values and goals). Jul 22, 2015 at 14:32
  • Do you have any commercial interests in the project?
    – Philipp
    Jul 22, 2015 at 14:54
  • 2
    Hi Monty, didn't you move to the MariaDB project?
    – Alec Teal
    Jul 22, 2015 at 15:46
  • 2
    @AbhiBeckert Your comment should probably be an answer
    – kdopen
    Jul 22, 2015 at 16:37
  • @kdopen it's too short/low quality to be an answer and I haven't got time to improve it. Feel free to re-write my comment as an answer yourself if you want... it's CC-BY-SA after all :p Jul 22, 2015 at 20:28

5 Answers 5

23

Forking is not only a possibility of open source development, it's an express intention. If their fork is more popular than yours, this may be because they do something technically better than you, in which case you can merge back their patches if they operate under a compatible license.

If they are doing something socially better than you are, take notes and learn.

If it's just a differing direction they're taking, the fork created more choice, and yours proved the less popular one.

Personally, I never experienced a fork that didn't try to solve the problem internally first, but just unilaterally forked without much communication. Usually, a fork is made either with the intention to merge back, or as a last resort when views turn out irreconcilable.

11

If they're out-competing you, they've got something you haven't. This may be:

  • more updates
  • more in-demand features
  • more contributors
  • better publicity

Whatever it is, try to find out what it is. If they're doing more publicity stuff than you, then increase what you do. Run things like community ads on Stack Exchange - they're free, and they get eyeballs on your project. Try to attract more contributors, or try to update more frequently.

Often, engaging with your community is fairly effective: if you're seen to be engaged and proactive about the development of your product, people will recommend you to others, who will also recommend you, and you might get some new contributors and users that way.

If you want to be a little ethically unstable (not that I recommend this), look at your license. Is it GPL? If so, theirs must also be GPL, meaning you can copy things they've done with some attribution. This may encourage people to use your version, because you now have the features they want too, but beware that if people find out you've been copying features and trying to hide the fact - although it's legally sound - it may not give you a very socially sound position. Of course, if your licenses are compatible, you can just copy the features and be open about it :)

Ultimately though, there may not be a huge amount you can do. However, you can console yourself with the fact that you started it, and that your copyright notices will forever have to live on in the code of their fork.

0
9

The main questions to resolve: Why did they fork? What's at stake for them? Similarly, what's at stake for you?

You say they aren't receptive to your changes, but did they ever submit patches/pull requests to yours? Without communication, you cannot effectively collaborate, even if you share coding and technical styles. So if they are just determined to do it their way without you, then the best you can hope for is to both develop awesome features and frequently borrow changes from each other.

If you are adding/maintaining features they want and they are adding/maintaining features you want, you don't necessarily have to be working on the same project, but your work should relate to each other's. This would be aided by increasing the modularity, configurability and flexibility of your architecture, i.e. so you might have projects MyProject and TheirProject share a Project-Common library/gem/module/whatever. (Note: such refactoring is non-trivial, increases release-packaging time/cost and still requires cooperation. But it is a good way to minimize the divergence in forks.)

I fundamentally disagree that pulling features from their fork would be socially questionable. License permitting, it would be by far preferred to keep the projects in sync instead of building a competing reimplementation.

Do you have a user community? Do they? Existing adopters have an interest in continuity. New users just want the better package.

To me it sounds like your main concerns are with control and to a lesser extent, dilution of project prominence. I would say don't sweat those too much. You have a repo you control directly and the fork doesn't change that. Even if their project becomes rapidly more popular and hugely divergent, you can always tout yours as "the project TheirProject started from".

7

Your project's come to life! Other people are very interested in working on it. The end result will benefit mankind, or at least the portion that needs whatever your project does.

The alternative would be working hard on a project, and nobody cares. At least this way, your project will live, past the point you lose interest in it, or are unable to contribute. As the originator you have useful advice and guidance to give to contributors. Though of course it's their work they're doing, so ultimately they choose what they do. Hopefully an informal consensus will organise itself, and it'll go along well.

That's what happens with open source, it's the whole idea. That's WHY open source becomes popular! You've created a baby, and now it's making friends and growing to become a part of the world. It won't always act as you want it to, but you're it's father and always will be. Wish it luck, and congratulate yourself on a job well done. This is how open-source is supposed to end up. That, or being forgotten. You did well!

6

Fork their fork and make it even better! Take all their changes and add the stuff that people ask for and get denied and you will soon be the real deal again .. this fork is brought to you from the original developer of XY .. don't forget to thank the guys! ;-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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