[Quantlib-dev] Plans for future releases and call for contributions

[Luigi B. <lui...@gm...>]

Hi all,
    first of all, I'd like to say thanks to everybody who helped us
releasing QuantLib 0.4.0 (as well as all previous releases) by
contributing code, bug reports, comments---you name it. It's been a
great six years.

This year, we're planning to finally take the next step and release
QuantLib 1.0.  I'll draft a plan and ask for specific contributions
later in this post; but before that, please let me share a few thoughts.

Lately I started to have the feeling that our development model has
reached its limit. Until now, development of the library has been pushed
forwards by a few dedicated individuals and by occasional contributions
by other people. However, there's only so much that this can achieve; as
witnessed, to name a couple of examples, by the lack of user
documentation and my systematic delay in answering posts to the mailing
lists.

In short, we need to foster a community. We didn't give much effort to
this so far; actually, I'm afraid we (the core developers) might have
scared potential contributors away. Until now, we have had a somewhat
cavalier attitude---when we wanted to do something, we just opened our
editors and IDEs and started hacking. (Me? Guilty as charged.)
Unfortunately, this might give the impression that the library is our
playground and discourage people from entering our supposedly closed
club.

This will have to change. I'll try and bounce ideas on the developer
mailing list before any major change. Of course, I also encourage the
other developers to do the same---kudos to those that already do. In
short, I'll do my best so that the library is owned (and felt as such)
by the whole community gravitating around the mailing lists.

Enough---and onwards to the plan for release 1.0.

My idea (open to discussion, of course) was to get to 1.0 in two or
three releases. The ones before 1.0 will give us a chance to make
changes we've intended to do for quite a while, but that could not be
done easily in a backward-compatible way. Some of them were made
already.

The next step would be QuantLib 1.0. In fact, the release before that
one (0.9.0?) would almost be a beta release of 1.0. I wouldn't change
much between the two; instead, I would focus on improving documentation
and general usability (a task which should already start for the
upcoming releases.)

Needless to say, all such releases (as well as future ones) will need
your contribution. You don't need to do anything exceptional; each of
you can help by giving as little time and effort you can afford or want
to spare.

The easiest way to contribute would be to subscribe to the QuantLib-dev
mailing list (the subscription page can be found at
<https://lists.sourceforge.net/lists/listinfo/quantlib-dev>.) As I said,
we'll try and discuss future developments there. Your contribution to
the discussions, even if only an occasional one, will be useful.

If you think you can get more involved, there's a number of other things
you can do - apart from contributing code or patches to the library, of
course. A few of them are:

- answer questions on the QuantLib-users mailing list;

- subscribe to the QuantLib-cvs mailing list and review the changes
  committed to the repository. You might ask questions about the
  change, make further suggestions, or report a bug you spotted. I'll
  try and setup the mailing list so that replies to posts go to
  QuantLib-dev.

- provide examples. Those are easier to write than new parts of the
  library, and are immensely useful to new users as they can act as
  documentation of library features and their usage. If you don't have
  the time to provide examples, you can still contribute by writing to
  QuantLib-dev and proposing examples to be written by whoever accepts
  the task.

- We might put some kind of cookbook on the wiki (we'll have to
  discuss the idea on the list.) In this case, you might provide code
  snippets exemplifying how to perform simple (or less simple)
  tasks. This would require less effort than full-fledged examples.

All of the above are ways to contribute. Even if contributions were
little, their cumulative effect would be a great help to improve the
library. Moreover, each of the above are also ways to familiarize with
the library and in time to become able to work on its internals.

Thanks for listening. Comments are welcome.

Later,
        Luigi


---------------------------------------- 

fix, n.,v. 
What one does when a problem has been reported too many times 
to be ignored. 
-- the Jargon file