Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

POCO Anniversary, Past and Future

Filed under: Uncategorized by guenter at 22:52

These days in September 2004, five years ago, I started working on a set of C++ libraries that would reflect my idea of how to write proper C++ programs. What I wanted was a set of C++ libraries for the internet age. Easy to use and quick to learn for those already familiar with things like the Java Class Library or the .NET framework. And yet something that was true C++, combining the best of classic and modern C++. With source code that’s a joy, not a pain, to look at. After a few months of work (beside the consulting/contracting work I was doing at the time), the first public release of the C++ Portable Components, as it was called back then, was on February 21, 2005. Only a few months later, Alex joined the project as first contributor. Fast forward five years. POCO has become one of the more popular C++ class libraries. Lots of people have been building amazing applications with POCO. For a small sample, just look at the Wiki.

Now we would like to take POCO to the next level. As you probably have noticed, development work on new features has slowed down quite a bit in the recent months. While we have (had) a few people contributing significant amounts of work to the project, most of the work is still being done by Alex and myself. And this is where the main problem lies. While we both really enjoy working on POCO, we have to do other jobs as well — mostly because, for the most part, it’s these other jobs that pay our bills and nurture our families. In my case it’s work on consulting jobs, as well as my company’s commercial product offerings; in Alex’s case its his day job. This does not leave enough time to bring POCO to where we’d like it to be (more on that in an upcoming post). What the project would really need right now is the equivalent of one software developer working full time on POCO. Now, here in Europe, a full time software developer costs a minimum of around EUR 60.000 a year. That’s a lot of money. The original plan was to eventually make enough money from commercial support contracts to fund the ongoing development of POCO. That was a great plan, only it did not work out. Most people simply don’t need support (which, ironic as it may sound, is actually the goal of any good product) or, for various reasons, don’t want to pay for it. Now, my company does have valued customers paying a good amount of money for support and licenses. But this is almost all for my company’s commercial products, so development of these products is what the revenues are used for.

To make a long story short, what I want to introduce is a donation and sponsorship program for the POCO project. Similar to what other open source projects do, various sponsorship levels are planned. Sponsors will be acknowledged on the website, as well as in source code releases. The ultimate goal is to have a new organization — the POCO Foundation — oversee management of donations. Donations will, of course, be exclusively used for the ongoing development of POCO. The exact details of how all this will work haven’t been set in stone yet, so any input is welcome. Of course, anyone wanting to contribute significant amounts of work time instead of money is very welcome as well.

9 Comments »
  1. So… that begs the question, what is ‘a significant amount of work time’ or even a significant donation?

    Cheers,
    Seth

    Comment by Seth on September 28, 2009, 00:39

  2. Why not just submit the relevant parts of POCO as a boost library?Remove all the duplicated components such as boost::shared_ptr Poco::AutoPtr and concentrate on adding missing value to the boost libraries.

    Comment by Brad Phelan on September 28, 2009, 10:09

  3. @Brad: I fear you may have missed the point from PoCo’s mission statement. Freely from http://pocoproject.org/info/why.html:

    * 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

    Comment by Seth on September 28, 2009, 10:31

  4. Seth:

    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 …

    Comment by alex on September 28, 2009, 13:46

  5. Alex,

    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

    Comment by Brad Phelan on September 28, 2009, 15:41

  6. Brad,

    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.

    Comment by alex on September 28, 2009, 17:23

  7. > The original plan was to eventually make enough money from commercial support contracts to fund the ongoing development of POCO.

    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.

    Comment by James Mansion on September 30, 2009, 13:40

  8. > 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.

    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.

    Comment by guenter on October 1, 2009, 07:38

  9. I really think Poco belongs on GitHub. I think you might see more contributions to it and it truly has a chance to grow.

    Comment by John on October 5, 2009, 04:06

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment