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.
X.org is a fork and successful indeed. MariaDB was as necessary answer to MySQL closed for community-driven development.
And is a fork -- everybody could have continued with contributing to MySQL and assigning rights to Sun (now Oracle), and most of the (public) innovation is happening on the MariaDB side.
Though, I haven't seen a lot of critical mass around MariaDB.
Yet. ;)
Dean Michael Berris wrote:
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.
In many cases it meets same problems as any other startup project.
Sure, but the maintenance problem that was there is solved by the new project because the new one is maintained at the time of the fork.
Dean Michael Berris wrote:
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. Support fora -- well, you can (easily) create mailing lists now and even online web forums to provide community support. Funding -- well, it's the same issue that any other open source project faces anyway, I don't see why a fork would be especially harder to fund than any other project. With forks, you'd have that "scratch your own itch" and "build it and they will come" mantra's. Unless you do both, you're not going to get far, and this applies to any open source software project.
Forking a project is similar to this story: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks. let's leave it and make new Rome v2 in south-west.
Dean Michael Berris wrote:
That's a re-write, not a fork. A fork would be:
Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks; who's with me, I'm going to bring the good parts of Rome and build a city that's in the south-west but this time with dedicated cleaners, hospitals, proper waste management facilities, and cool new sights.
I've assumed the "bringin the good parts". I should have made it clear.
See, the other part you missed is the question "who's with me?". Anybody can fork any open source project, that's a given -- but then getting critical mass behind you to be successful is something else. Now, let's say you are charismatic and can get people behind you to leave the original project behind and take the fork to a different direction, then I don't know what the problem with forking is -- aside from, well, potentially killing the original project, which sometimes, is a good thing.
Dean Michael Berris wrote:
I joined this thread because I could not understand the sociological aspect of this decision. Perhaps it's me and nowadays more folks consider it easier to quit a job than to work out a compromise :-) I honestly wish Artyom good luck.
Well, these days I think at least compromises seem to be overrated. If you can't get to Win/Win, there's always No Deal. ;)
I don't think compromises are overrated.
Hehe, to each his own then. ;)
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".
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. ;)
Best regards,
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. This might just be me though. ;) -- Dean Michael Berris deanberris.com