Text: about forks
This is an answer to Chromium: Why it isn't in Fedora yet as a proper package.
I am myself an Open Source developer and developer/lead of some OSS projects. And I have made also experience with exactly the issue you are pointing at - from a developers point of you (i.e. the same view as Google in this case). It seems to me that you mostly have the view/experience from a distribution packager.
I fully agree with you that forks are bad. Google also doesn't really want them, nor does any other developer. Here are some of the problems you have as a developer:
Example case: You need some functionallity, let's say for reading a ZIP-file and accessing the uncompressed data on-the-fly, i.e. without extracting it on disk. You search around for an existing lib, which may also support RAR, 7z and maybe other formats. You don't really find any lib which gives you the full functionality you want, though, i.e. to have a transparent filesystem kind-of access to the content and maybe be able to even extract ZIP files on-the-fly which are inside of another ZIP-file. But it doesn't seem to be complicated in your lib of choice to add such functionality. I.e. you decide to add it, suited exactly to your needs. To ask the developers of the lib to do it is not really an option because you don't want to wait for that, you want to continue on your project itself and not wait for other people / project teams which can take some time. So there you have your own fork. Of course it is planned to get these changes back into the original lib and make the fork redundant. As long as this is not done, you keep your own copy (fork) of it. Now, at this point, which is very common in many big OSS projects, you probably would want to make a patch with your changes and hand it over to the lib upstream. There is the problem: This takes additional work and probably has low priority in your own project, unless you have many free resources (but who has them). Also, you may hope that somebody else will just do it for you. And not only will it take work for a clean patch: There high chances that upstream don't want to apply your patch. Maybe the changes are too hacky, or too radical, or upstream just don't have time to review it. This means further work/time and interaction with the lib dev-team, further work on the lib-changes (which are of none use for your own project) and some back and forth with the lib dev-team. Then, let's say you have gotten to a point where it is applied upstream and in sync with your own copy, you still have a problem: It will take a while, often a long time until these things go into the common Linux distributions. First, the lib dev-team probably decides to not make a new release right away for your patches but to just include it in the next major release, which may come at some unspecific day. This can take a while. Then, when this is done, on many Linux distributions, it takes a long time until it goes into the stable repository. It is not an option for your project to wait for this. I.e., it means that until you can be sure that it will be included in most Linux distributions, you anyway need to distribute your own copy of the lib with it. Don't get this wrong - you would be really happy if it comes to this end, because it means less maintaining work for yourself.
This example case is not really that uncommon. And it is already simplified a lot. In many cases, you have the need of applying further patches from time to time. In the example, you may see after some later time, that you need again another function in the lib which is not there right now. It is probably easier now to get it to upstream, as you already have the contact to them, but again it will take much too long time for you until it would be available in common Linux distributions (wait for the next release of the lib, wait until it goes into most Linux distris stable repo).
And there is another problem: You are dependend on the stability of the lib. In cases where the lib development is very active and the maintaining is good, this is not a problem. In many cases though, the development of some libs is very quiet and the maintainer(s) are too busy to even review your patches. Maybe you just have fixed some performance issue in the lib. But if you care about the quality of your software, you want to have it behaving the same way on all systems. I.e. it wouldn't be an option if your software performs badly or even doesn't work correct on some systems where the lib is outdated and good on others. And the user of your software will blame your software for it, he probably will not know that it is some outdated lib on his system which makes it performing bad. If you want to keep the overall feeling of your software stability as good, this may be important.
Things can become also even more complicated if you have the same problem with multiple libs, which may depend on each other. It can mean that one of your forked libs only works together with another of your forked libs. That means that until you can get the patch for one lib to upstream, you first need to get the patch for another lib to upstream.
After all, it is also a matter of being productive. The developer mostly cares about getting things done, make his software just working and stable. And his resources are always limited, so he searches for the easiest and fastest way. And I cannot really blame him for this. Now, when he has done some own work on some external lib and just put his own copy of the lib into his software, he probably went on with other things (working on the project itself) instead of putting work into getting these things back into the lib upstream. He probably hopes that someone else will do this work for him.
So, is this really that bad? He already is providing his own work for free and in addition he has published his work / additions on the lib.
So, for people who like to solve these issues, blaming someone (in this case Google) for putting to less work into this is not really the right way. Instead we should try to get the patches of Google into all the other projects and get this also to all stable repos of all Linux distributions. And when is has come to this state, at least for some specific libs, so that Googles fork became obsolete, they probably will reconsider if they should drop their own copy of the lib and depend on the system one.
If you want to support my work, please donate via Gittip/Flattr here: some text about forks
The text published here is under the copyright of Albert Zeyer. Distribution is only allowed with a reference to this page.
- Other documents
Albert Zeyer (Mail) Homepage with many open source projects including source code, artworks, both images and music, pictures and some writings about technical stuff, tutorials and some stories.
You are the 1228964th guy, who was able to find this site.
"Open sesame!" squealed the blue-eyed home-coming queen as the clam shucking faggot butler ravished her pendulous mounds and squeezed his trunklike dong into her pulsing slot machine.
22:15:14 up 488 days, 4:34, 1 user, load average: 0.03, 0.03, 0.05
The code can be seen here. Please contact me if you find any problems. :)