On 15/12/10 13:42, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 8:54 PM, mloskot<mateusz@loskot.net> wrote:
Dean Michael Berris wrote:
Here's the thing though, if the fork succeeds, it eventually becomes the "main" project. This has already happened with MariaDB and MySQL, Firefox and Mozilla, X11 and X.org, etc.
Firefox is not a fork, but the same team and the same organization decided to change their strategy from the Mozilla Suite to two separate products.
Which is by definition, a fork.
Technically, yes but organizationally no. The same organization, the same people. I'll remind, I'm considering a project as the whole machine producing a code. A project is not only a code.
The fact that something is unmaintained and that people other than the original maintainers want to maintain a fork of it, I don't see how it introduces a new maintenance problem.
There are plenty of new problems. Forking is not about copying, changing and throwing out on the public server.
Eh? That's the simplest definition of a fork. Unless I'm missing what you mean by fork.
I've tried to explain it at least two times.
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github).
Eh?
Yes, it's not just copying a code, as long as we both understand a project is not only a source code. Code is an extremely important part of a project, but it's not critical part. As every piece of software is useless without data, any forked source code is dead without community which uses and maintains it.
So, what else is there aside from code/documentation in an open source software project?
Community of users and developers -- well, if it's a fork, you can build that community on your own or potentially get people from the original project.
You can or you can not. There are plenty of reasons why users and developers won't drift with forks.
Support fora -- well, you can (easily) create mailing lists now and even online web forums to provide community support.
Technically, it's easy. Next, you have to have time to maintain the traffic, answer questions, provide support. When you have 100 folks subscribed, it's easy to spend 2 hours a day on it.
My general point is that it's easy to fork (as it's easy to create new FOSS project), but following steps are very difficult to make it success. What I have observed here, is what I'd call "premature forking" and that's why I don't understand such decisions.
Okay, but making something successful involves work -- regardless of whether it's the fork or the original project. So I don't see why forking should be discouraged even if there is no good reason to do it aside from "well, because I can and I want to".
You still don't understand my point. I'm not trying to discourage forking. I'm not suggesting forks are evil. I'm commenting very specific situation which has emerged and the reasons which are unclear to me.
Here is article that precisely explains my concerns, especially:
When to fork? When you have exhausted all other options.
http://fossfaq.com/questions/52/what-does-it-mean-to-fork-an-open-source-pro...
I have not seen such exhaustion.
I actually disagree with that answer.
You fork when:
- You want to.
It should be that simple really. ;)
We all are free as wild pigs and we can do whatever we wish. I'm trying to stay with frames of reasonable thinking and strategic planning, with some principles of business. If there is no pragmatism and rationale behind your decision but "want to" then it's ego-driven development.
HTH
By the way, my assertion is that forking, in general, isn't a bad thing; that diversification should be encouraged especially if it will bring innovation and covering new ground. The consolidation can happen later on when the good ideas can start cross-pollinating across the diverse tracks, and improve the overall state of the art.
I am by no means willing or even remotely considering forking Boost libraries -- especially since I cannot maintain any new Boost libraries other than the one I intend to submit for review and develop on my own. However I don't see why anybody who has the wherewithal or the motivation to actually either take over some of the Boost libraries in a fork -- heck, or the whole Boost project for that matter -- should be discouraged from doing so.
I agree with this, actually, but it's slightly far from the point of this specific situation I've tried to ask about and understand. If someone says "I don't want to do it, to maintain new piece of software myself, but I have no choice" but there is no track of discussion that would lead to such conclusions, then I'm far from understanding such what's the real reason. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org