Many of the successful open source projects have already noticed the elephant. Most successful open source projects are funded either by companies employing people to work on open source projects, or on significant financial donations. There’s just no other way to do it. I mean, we can continue working the way we are on POCO, and we’ll bring out one or two releases a year (mostly bugfixes and whatever new features we happen to need or find useful in our “regular” work). But this will mean that we’ll stay with 1.3.x (or maybe 1.4.x) and the trunk for the foreseeable future, as there’s just no time (and, to be honest, a lack of motivation to sacrifice our spare time and family live) to work on a proper 2.0 release. Or, we can attempt to get funding or company-backed contributors and move forward.

> Is there any expectation that this person will be an employee of Applied Informatics? Is there any reason not to retain someone from a developing nation with a lower cost base – apart from the usual issues with remote management, but you’ll get that for anyone who isn’t right there with you, on your payroll.

The plan is to set up a non-profit organization which manages the donations and pays contributors for their work. I guess it would be in the best interest of everyone if the current contributors would continue their work and get paid for it, even if this would cost more than entirely outsourcing development to a developing nation (or someone who has never worked on POCO before).

> Why not define work packages for batches of integration work and outsource them by bid?

This may be an additional option.

> It will be more palatable to donate if there were some concensus formed about the prioritisation of work.

We have a wiki and a forum and lots of ideas. What’s needed is more feedback (how do other people feel about backwards-compatibility breaking changes in 2.0, for example) and some organization.

I have a nasty suspicion that this is in fact the white elephant in the room for open source as a whole, unless you can lock in a few rich customers who will pay. Sooner or later there will have to be some frank disclosures of the financial realities of monetising open source, and perhaps a re-assessment.

> in Europe, a full time software developer costs a minimum of around EUR 60.000 a year.

Is there any expectation that this person will be an employee of Applied Informatics? Is there any reason not to retain someone from a developing nation with a lower cost base – apart from the usual issues with remote management, but you’ll get that for anyone who isn’t right there with you, on your payroll.

Why not define work packages for batches of integration work and outsource them by bid?

It will be more palatable to donate if there were some concensus formed about the prioritisation of work.

Many people use Boost and POCO together – it’s logical to do that if you benefit from both. I am not arguing which one is better here. I’m only saying that merger is not likely to happen. Let’s not hijack this discussion thread – I have opened a topic in the forum, so we can talk about it there.

I think there are two different types of C++ libraries.

(1) Libraries that abstract a specific feature away. ie XML, SQL, HTTP etc.

(2) Libraries that abstract programming concepts away. Containers, Algorithms, Flow control, Design patterns.

Poco is very good at (1) and very poor at (2) that is why I use both boost and Poco together.

B

A significant amount is one that makes a notable difference – if someone takes up to contribute a library or push out the next release, that would be significant. It is, however, worth mentioning that every new library contribution necessarily implies the future maintenance load that has to be carried by someone. We do have a lot of great contributors to whom we are very grateful – people submit lots of bug reports and fixes as well as whole libraries. What we lack is someone with a constant focus on the receiving end – a person continuously incorporating the contributions, maintaining the framework as a whole and doing the releases on a reguar schedule.

As for the money, Guenter has pointed out how much it would cost to have a person work full-time on POCO. From my experience, one full-time person would be sufficient for the time being. If all the POCO users, commercial and otherwise, chipped in and contributed something towards this goal, the outcome would be a steady progress and regular release schedule. It would also give the contributors certain amount of control (commensurate with the donation size) in steering the features towards the areas of their interest as well as guarantees of bug fixes within certain timeframe.

Brad:

Adding parts of POCO to Boost is not likely to happen. I certainly would not venture so far to say that things can not get done with Boost, but there are quite a few things we prefer to do differently. Boost is maintained by some smart folks, provides solid libraries and also serves as testing ground for new C++ features. It does, however, strike me as a bunch of libraries (mostly in headers) thrown together as opposed to POCO’s coherent and practical framework approach – portably and systematically abstracting things developer needs every day – processes, network, XML, database access etc …

* You prefer readable, easily understandable code over sophisticated and overly complicated C++ puzzles that challenge your compiler, yourself and your coworkers.

* You are looking for class libraries with a clean code base that is not contaminated by thousands of #ifdef’s for supporting some obscure obsolete platforms you’ve never heard about.

* You want to get things done.

Just my $0.02

Cheers,
Seth