On 15/12/10 06:58, Artyom wrote:

Mateusz Loskot wrote:

...

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.

CppDB is not a fork of SOCI, it is totally different library that does things very differently that does not share a single line of code with SOCI.

I admit that I had took many general ideas from SOCI and made them more suitable for my vision how SQL library should look, and this is very logical since SOCI was the best SQL library I used so far (till CppDB was released :-) ).

This is what I called as forking. Forking does not necessarily mean code copying. Generally, the CppDB look and feel is very similar.

And as you know (and you are as you on soci's mailing list) that I still do my small contributions to SOCI - each time I find some issue I try to fix it, report it and even send a patch.

Yes of course I know and this is always highly appreciated.

As FOSS project developer and leader I know how valuable it is.

Indeed.

Now I'll explain the decision more deeply: ------------------------------------------

I was considering join the SOCI project and bring some improvements, however my vision of how the stuff should work and SOCI's vision was quite different, and the internal structure of the SOCI project and class relationships did bringing new and significant features to SOCI was not as simple as I was thinking.

All the 5 points you listed as clear advantages http://lists.boost.org/Archives/boost/2010/12/173982.php state, in my opinion, features missing from SOCI which have been planned (3, 4) or are possible to implement (1, 2, 5). The "few additional points" 1) is possible to overcome, certainly. The point about "matter of taste" is what I call ego-related issue in a software development.

2. Push new things to SOCI fighting to explain my vision of things, missing some of them and finally not getting what I need.

Assuming a fight straight away is an unfortunate attitude.

3. Create my own library that provides the vision I need.

So I had chousen the 3rd.

However I had **another** reason to do this as well.

As you probably know I'm developer of CppCMS framework, and I need a good database connectivity solution for my customers, and what is most important I need it to be stable, useable with fast upstream bug fixes, optimized for performance and I need it **now**.

stable - SOCI is stable usable - SOCI is usable, unless you show what usability issues CppDB solves, I have no reason to take this point. fast upstream bug fixes - it's a matter of man power and writing your own library will solve it in short term only. performance - any specific measures and benchmarks? It's possible to profile and improve SOCI, of course. I've observed your general disappointment in many other packages, Boost included. Especially about the stability, as you call it. Perhaps, you've went for a wrong programming language or wrong toolkit (Boost vs Qt).

SOCI couldn't do this for me, as it is still stuck in version 3.0.0 released in 2008 with no bug fixes. And I can't say to my customers - take a git version of SOCI it is very nice (that 9 hours ago was broken and probably still broken now - I've send a patch to SOCI's list)

The reason is the same as the reason in Boost. Why haven't you asked for commit access on the mailing list?

...

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?

Anyways, I'm just disappointed how much FOSS is ego-driven where it should mean collaboration. Just pity.

Mateusz,

as I explained above it is not about the ego, even thou there are many things I can be proud of. It is about having a solution.

I probably have used word "ego" with my personal interpretation.

Beleive me I prefer spending my time of fixing bugs and providing new features in CppCMS then writing an SQL library.

1. Introduce your idea and request for comments 2. Present implementation, patches, etc. 3. Ask for commit access. 4. Be a part of a team and decision process. I've been a member of FOSS projects with long (5+) and and very long (10+ and ~80 committers) history and that's how things work there. Sometimes your idea is dropped, sometimes deferred, sometimes accepted. Being able to work out a compromise and being able to *accept* a compromise is what makes a project less ego-centric but with chances to survive. A project will survive only if there is a constantly growing community of users and developers. As an author of a software, I rather value more a new committer joining my team, than the fact that I'm able to force any idea and flavours I want myself.

Best Regards and I hope your undersand the resasons I had.

I understand the reasons. I don't understand the manner you've decided to solve your problems. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org