Re: [Quickfix-developers] Unresolved stability issue in rev 2300
Brought to you by:
orenmnero
From: K. F. <kfr...@gm...> - 2013-06-17 16:12:05
|
Hello Brian - Thank you for this information. I have a question and some comments, below. On Mon, Jun 17, 2013 at 11:14 AM, Brian Erst <azz...@ya...> wrote: > > As much as I hate to say it (as QF has been very good), the only time you get traction on fixes/releases is when someone threatens to fork the project. Please let me also express my thanks for QuickFix. It is good and useful. Although not as good as the very best open-source projects, it is much better than the vast majority of them. > This project lay pretty fallow from 2006-2009, stuck on 1.12.4 (which didn't even support FIX 5.0, released in 2006) until, in March of 2009, developers got so frustrated that a fork was discussed pretty seriously. Suddenly, there was renewed interest by Oren/Connamara, but QuickFix 1.13.0 still took an entire year (Feb 26, 2010) to be released. A couple of quick bug fix releases over the next few months and then... nothing again for three years. > > Connamara is a busy consulting firm and has long since moved on from any sort of active management/development of QuickFIX. Oren hasn't even participated in the forum since January of 2011. I don't blame them - they have lots of paying customers for their projects and are quite busy. Their bread and butter comes from .Net development - look at the change log of QuickFIX/n (https://github.com/connamara/quickfixn/commits/master) and see the frequent, active development of that system (four pages of commits this year alone). > > Management of traditional QuickFIX should be moved to a more active developer community with thanks to Oren and Connamara for getting it to where it is. My question is whether the problem is that Connamara hasn't been doing the core work (i.e., fixing the bugs and writing the code for new features), or whether they haven't been managing the open-source project in a way that it is practical for others in the community to do the work (i.e., submit patches). If the QuickFix project is being managed in a way that it is practical and reasonably convenient for, for example, me to submit a patch, and if the patch is legitimate, have it reviewed, upstreamed, and released in a timely manner, then I would see no need to fork and/or move to a different community. As long as Connamara is managing the project effectively (as distinct from doing the work), and if Connamara feels (their decision, of course) that they don't have the resources to fix a bug or implement a new feature, I don't see why forking or moving the project would cause those missing resources to suddenly appear. (Now if Connamara were impeding progress, either though inattention or by rejecting legitimate patches, then that would be a good reason to fork the project or change its governance. I do see that Viktor was asking after a patch of his that hadn't been reviewed in over a year. Is Connamara the only entity that can review / accept / merge patches? If so, perhaps that's a problem, and the governance should be tweaked.) If you want or need something in an open-source project, you generally: hope someone else does it; do it yourself; pay somebody to do it; or do without. For example, I wanted to be able to use QuickFix on windows, but have it built with a windows port of gcc (mingw-w64), rather than with msvc. QuickFix wouldn't build with mingw-w64 out of the box, so I "ported" it from msvc to mingw-w64. When I had questions about bits of code I wasn't sure about I got the support I needed on this list, primarily from Connamara. (I had the sense that I was all alone out here in left field trying to use mingw-w64 -- my sense is that everybody using QuickFix on windows wants to use msvc -- so I did not do the additional work that would have been needed to turn my port into a clean patch and try to get it merged into the official QuickFix release.) > - Brian Erst Happy QuickFix Hacking! K. Frank |