On Wed, Dec 15, 2010 at 7:45 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15/12/10 02:20, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot<mateusz@loskot.net> wrote:
Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it.
I'm not sure but is CppDB a fork of SOCI?
It is not a direct fork of code. I believe I explained it in my reply to Artyom's post.
Yep, read that too. I just wanted to check if my understanding of "fork" was correct.
This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked?
Well... actually... forks are a valid means of diversification in FOSS projects.
Technically and formally valid, but not necessarily valid in terms of sustainability. Thinking in terms of r/K selection theory, which one would be better for FOSS (assuming no funds).
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. -- there's no "sacredness of the root" when it comes to FOSS, and I think that's a good thing. This means, if the original project wasn't going according to a number of contributor's (or community members') liking, then forking is always an option. The reason most forks exist is that the original approach is not sustainable. Sustainability in the sense that original design/process decisions were deemed wrong by some people and that they think it's better to either do it over or gut the software/project and bring it to a new direction than trying to fix the original. This is where the concept of a non-sacred source makes sense -- think how CMUCL got forked into many various CL implementations and how each one has thrived. Also, sometimes, having just one project isn't also sustainable -- which is why forks make sense for a means of diversification and innovation. ;)
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained".
Forking never solves maintenance problems, but introduces new ones.
Not really. 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. The fork might be more actively maintained by the people that forked the original project, or the new project allows more contributors to get involved, or offers a better means of iterating/innovating than the original project... in that situation the non-maintenance project is actually solved by allowing others to maintain it outside the original project.
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?
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.
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 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. ;) -- Dean Michael Berris deanberris.com