Budget use in the TYPO3 Phoenix and FLOW3 project

Update: I updated this post to re-add the files that seem to have been lost when migrating to the new typo3.org. Since 2011 I am the "budget responsible" for the TYPO3 Phoenix project. This means all invoices that are to be paid from the budget must be approved by me, before the TYPO3 Association pays them. There is one exception to the rule: my own invoices. Those are sent to Christian Jul Jensen for a check, a mechanism the Steering Committee set up to avoid self-approvals in cases like this. (At the time of writing this process is little bit off track, as the Steering Committe does not exist any longer after the recent General Assembly of the TYPO3 Association.) This post will show the budget applications for 2011 and 2012 as well as how the budget was spent. Before we dive into the details, let me explain some of the things you are about to see in the documents.

• The spreadsheets contain hours per month. Those are hours worked, so any holiday hours are not contained in those numbers. Furthermore, those numbers are minimum hours worked, as everyone on the team most of the time works more than is invoiced…
• Expenses mostly cover JiffyBox costs. Since we have a server team and a number of servers available for the TYPO3 project, you might see these as a waste of money. What you have to keep in mind, is that the use of project infrastructure was not always possible as easy and fast as it is now. When working on a project, sometimes it saves your butt if you are able to fire up a new machine or Apache instance within ten minutes instead of waiting a few days. That being said: we'll be working with the server team in the coming weeks to move those setups to the project's sponsored infrastructure.
• In 2011 there was a rule set for holidays in place. Those "working full time" for the TYPO3 Association (including not being allowed to take on other paid assignments) were given 20 days of holidays to use throughout the year. For 2012 that rule was dropped (because it was confusing and did not benefit everyone) in favor of a ten percent increase of the hourly rate.
• Last not least there is a graph titled Remaining Budget (Estimate) in the spreadsheets. It is a projection of the money spent, with the estimated costs being typeset in red. As invoices come in, those numbers are replaced by the real ones.

2011 For 2011 the project applied for 266.800 € and was granted a little less than 210.000 €. Later in the year we split off 6.000 € to cover some risk in the BLE project (that is the "shifted to BLE" number in the spreadsheet). More than 3600 hours were accounted for, but more were actually worked (see above). We had a number of meetings in a greater circle (the Code Sprint in Berlin and the T3DD11) and a code sprint in Lübeck where the team spent a whole week together. The expenses paid can be found on the second page, consisting of a flat for everyone to stay and the meeting place as well as some travel costs paid to Sebastian - balance that against the 70 hours he did not invoice because "the sprint was a fun thing" and we come out really cheap. :) In the end a part of the budgeted money was not used, mostly because costs were lower (to a large degree due to the fact that Jens never invoiced anything). 2012 For 2012 the project applied for 247.000 € and was granted 197.600 € for development. An independent budget of 24.000 € is reserved for work on the UX/UI. In addition to that there is the joint budget of 36.000 € to be used by the v4 and Phoenix teams together - <link http: lists.typo3.org pipermail typo3-team-core _blank>information on that can be found in this announcement. The initial budget application was presented during the T3CON11 in Hanau and some of the feedback we got there was included in a revised version. This lead to some clarifications as well as a list of features the version we plan to release later this year will have. The estimate includes the diminishing TYPO3 Association funding for Robert Lemke and myself in the third and fourth quarter of the year, which we hope to offset by external sponsoring and projects benefitting the project. As the year is still young, there's not much more to say. 2013, 2014, … We hope that Phoenix will, once it is released, see market adoption in a way that eventually makes it possible to finance mostly maintenance while the development is made possible differently - much like it is the case for v4. Looking at the success of FLOW3 in that regard makes us optimistic, as we have rejected projects already (in favor of focusing on Phoenix). We'll see what the future brings… If you have any further questions of feedback, fire away in the comments or send me an email.