Phoenix Development

Added by Maik Hagenbruch over 6 years ago

Agile TYPO3 “Phoenix” and FLOW3 Development - Karsten Dambekalns

The development of the next generation CMS codenamed “Phoenix” progressed nicely over 2012, but is still far from being “done done”. Because market share and understanding of the advantages of Phoenix are still too low to enable self-igniting development fireworks, we plan to further pay developers for work on features. Through regular paid work as well as code sprints the most pressing issues and important features will be resolved.
Because the availability of team members and what will actually need to be done is unknown at this point (and simply cannot be planned that much in advance), we will employ an agile strategy based on SCRUM principles. To enable control over the budget use, we will coordinate the respective goals of the next sprint with the EAB and the team after each sprint.


Replies (36)

RE: Phoenix Development - Added by Jo Hasenau over 6 years ago

There seem to be some bugs in the Spreadsheet.

At least the total costs should be more than just 11.200 according to the table below.

RE: Phoenix Development - Added by Maik Hagenbruch over 6 years ago

Table updated.

RE: Phoenix Development - Added by Steffen Ritter over 6 years ago

I do not want to see 25days/month beeing payed for development. Now that there is a solid base, this should work on volunteer open source base.

The TYPO3 CMS did evolve features without so much paid coding, too. I'm pretty sure man things can be funded through customer projects...

FLOW3/Phoenix needs to get rid of "closed circle of payed developers" feeling. Until from the outside it feels your teams do not accept external input and stay on your own. I feel this won't change as long as there is that much paied work.

RE: Phoenix Development - Added by Claus Due over 6 years ago

One question:

Because market share and understanding of the advantages of Phoenix are still too low to enable self-igniting development fireworks, we plan to further pay developers for work on features.

Will the Phoenix team continue to work on Phoenix if they're no longer paid to do so?

RE: Phoenix Development - Added by Steffen Gebert over 6 years ago

I think there is a bunch of active, but (mostly) unpaid developers in the Phoenix team. So I don't really consider it a closed circle of developers.
As soon as people use the new CMS for real projects, the easier it will get to contribute to the Newcms core (man.. I'll be happy, when the new name is out!)

RE: Phoenix Development - Added by t3agent Christian Händel over 6 years ago

I support the comment of Steffen Ritter. The development part are 6 developers full day every month the whole year. I think with this manpower we can create a complete newCMS.

To accept this there must be a very detailed plan of features and milestones with a clear roadmap.

RE: Phoenix Development - Added by Claus Due over 6 years ago

To accept this there must be a very detailed plan of features and milestones with a clear roadmap.

I completely agree with this statement. It's actually mentioned in the requirements.

RE: Phoenix Development - Added by Jo Hasenau over 6 years ago

Steffen Ritter wrote:

this should work on volunteer open source base.

Maybe you are mistaking things here. Open Source says "Free as in free speech, not as in free beer" - it's not written anywhere, that open source software has to be coded on a voluntary base. It's just about code, that should be free to be modified by anyone else to his or her needs, nothing more, nothing less.

On the other hand I agree with the other arguments regarding clearly defined milestones. If people want to get paid they should at least be able to tell what they will be delivering for the money and when this will happen.

RE: Phoenix Development - Added by Steffen Ritter over 6 years ago

Jo Hasenau wrote:

Steffen Ritter wrote:

this should work on volunteer open source base.

Maybe you are mistaking things here. Open Source says "Free as in free speech, not as in free beer" - it's not written anywhere, that open source software has to be coded on a voluntary base.

It does not need to be free beer. And paying the foundation is fine with me - I just think that we are at the point, where enough "volunteer work" will bring the product way far enough. And "others" should pay it (with free-time, with customer money, with company money)...

RE: Phoenix Development - Added by Philipp Gampe over 6 years ago

I support the budget if there are clear milestones and those are communicated openly. I do not care if this happens now or during the year (scrum/agile/whatever). However if it turns out that the milestones can not be fulfilled, then the money should be blocked and used for other stuff, e.g. support code sprints.

RE: Phoenix Development - Added by Jochen Weiland over 6 years ago

The goal from last years budget application was "Development of TYPO3 Phoenix to a usable state and a first final release to the end of 2012" and "release a stable, functional version of the CMS in the fall of 2012". These goals have not (yet) been achieved. As of now, not even a list of features available in the first stable release has been published.

What is missing in the budget application is a list of features to be implemented in each of the planned releases and clearly defined milestones.

RE: Phoenix Development - Added by Karsten Dambekalns over 6 years ago

Hi.

t3agent wrote:

I support the comment of Steffen Ritter. The development part are 6 developers full day every month the whole year. I think with this manpower we can create a complete newCMS.

So with 138.600 Euro (all WT costs from the application, that means 2520 hours at the T3A rate) you develop a complete new CMS? Go ahead!

I think you have either misread the application or have fundamentally faster and/or cheaper developers at your disposal.

Regards,
Karsten

RE: Phoenix Development - Added by Karsten Dambekalns over 6 years ago

Hi.

Jochen Weiland wrote:

The goal from last years budget application was "Development of TYPO3 Phoenix to a usable state and a first final release to the end of 2012" and "release a stable, functional version of the CMS in the fall of 2012". These goals have not (yet) been achieved.

But fall has just started and the end of the year is not yet reached. While I understand the urge to assume we will fail the plan (again, after all we are years behind schedule), it still hurts.

As of now, not even a list of features available in the first stable release has been published.

That list of features was part of the budget application for 2012. It has been published by myself as part of http://typo3.org/news/article/budget-use-in-the-typo3-phoenix-and-flow3-project/ in March.

What is missing in the budget application is a list of features to be implemented in each of the planned releases and clearly defined milestones.

What is missing is a Project Owner for our scrum approach. People that actually take the initiative to define that plan with the team. We have been looking for input and people around that topic for (literally) years. We tried with various people, it never worked out (and I dare say it was not the team's fault).

Regards,
Karsten

RE: Phoenix Development - Added by Patrick Lobacher over 6 years ago

Perhaps I'm missing something but all I can see is an (huge) amount of money but no brief detailed explanation, detailed milestone plan, commitments, mission, vision of the project and so on - even less information than last year. So it would be impossible for the EAB (and the community) to track the progress.

In this stage I would give a -1 for the "WT" categories and a +1 for the code sprints.

RE: Phoenix Development - Added by Karsten Dambekalns over 6 years ago

Hi Patrick.

Patrick Lobacher wrote:

Perhaps I'm missing something but all I can see is an (huge) amount of money but no brief detailed explanation, detailed milestone plan, commitments, mission, vision of the project and so on - even less information than last year. So it would be impossible for the EAB (and the community) to track the progress.

As noted in the application:

Because the availability of team members and what will actually need to be done is unknown at this point (and simply cannot be planned that much in advance), we will employ an agile strategy based on SCRUM principles. To enable control over the budget use, we will coordinate the respective goals of the next sprint with the EAB and the team after each sprint

So if the EAB wants to track concrete goals, it needs to work with us, not against us. Also this implies that if goals are not reached and there is no acceptable explanation for that, money will be put on hold or the support will be abandoned.

<irony>
In the simplest case, send us a roadmap, most of you are CEO/CTO/C?? of an agency and obviously seem to have no problem in producing the needed plans. Here is the list of known factors, should be sufficient:

  • some people will be available
  • they will work some time per week
  • on some feature that will be needed
  • but it is sure people will need some features (phew!)
  • and they want those to be of high quality (of course!)

</irony>

No offense intended! Again, help us to define the goals, as I said, we have been looking for that help for years. Simply saying "you need to provide a plan" does not work.

RE: Phoenix Development - Added by Jochen Weiland over 6 years ago

Karsten Dambekalns wrote:

That list of features was part of the budget application for 2012. It has been published by myself as part of http://typo3.org/news/article/budget-use-in-the-typo3-phoenix-and-flow3-project/ in March.

Frankly, the version of the budget application that I have on file does not include any list of features. Probably they had been added later (when?). And the feature list is missing in the application for 2013.

RE: Phoenix Development - Added by Volker Graubaum over 6 years ago

@Karsten

First of all, I think we need money for Phoenix to bring it to a nice result. BUT!!!...

For my understanding: the problem is, in the moment you are developing without a goal (=Featurelist which says what is a "first final release")?

If it is, we have a big problem. I don't want to blame the developing team alone, but shouldn't you have stop in the moment you know that, and play the ball back to the Assoc?

On the otherside. You are BudgetOwner, so to say "I don't know what we are going to do, but I would like to develop more for Phoenix, and hopefully someone tells me what" isn't enough either.

You're right. Without a ProductOwner you can't make Scrum, but you say you are making Spints for years now.
So get your ProductOwner which defines goals. If it isn't found, the budget should be kicked. If it is found, the budget
should be changed so the goals can be reached, and IMHO it would be great if there is a budget which is not as high as in the application, but only about 50-70%. (since we don't have enough money for all applications)

Greetings Volker

RE: Phoenix Development - Added by Patrick Lobacher over 6 years ago

@Karsten: Not having a goal is not doing Scrum. Scrum is a project management method which regulates the way to the goal - not the goal itself. Without any vision and therefore a feature list (simply said) you can't do Scrum. Scrum is to sort out which feature is done in which sprint. But the feature itself (not to concrete but in general) should be known beforehand. Of course I could make you a list by myself - but I'm not representative what the majority of TYPO3 NKOTB User want to have in the future. For this position I have suggested kind of a TYPO3 CTO for a long time.

Another proposal: What about a "Feature Sprint" (compared to a code sprint) to define these goals together with at least some developer and CXO together in a e.g. 2-3 days meeting?

RE: Phoenix Development - Added by Jan-Hendrik Heuing over 6 years ago

It's good to see communication happening. Thank you all, and please keep going. Let's try to be constructive, feel free to ask questions about the past.

But please also mention how you like to see the future. Like Robert tweetet: Mention the features you would like to see.

We have discussed this budget before between the phoenix team and the EAB, and it seems hard to find an exact feature set, while still being in the early state. So the phoenix team decided to go for the scrum way instead. Which they mentioned in the application also. So for next year, they plan to not just doing what they like to do, but will work in cooperation with the EAB to define those next steps.

What it also needs here is a product owner "steering" the development. But it also needs feature requests to fulfill this procedure. If you have specific ideas for a feature set, or if you feel yourself capable of being a potential product owner, please get back to me or anyone else related to this, so we are able to find out more specific options.

I am really willing to get further with Phoenix. What we need is cooperation between all members of relating teams and externals, as well as communication and documentation. I am all in for supporting this. So let's see where we get to.

Please notice: This is my personal view, and is not related to any approvals for the final budget. No matter how the budgets will get approved, I'm, in for supporting it, if we find a way for communication, documentation and all the different bits.

So speaking about next year again: Please mention also what features you like to see, not only what went wrong in the past (which we still need to discuss so we're not doing the same thing again, dont get me wrong).

Jan-Hendrik

RE: Phoenix Development - Added by Volker Graubaum over 6 years ago

Another Idea how we can make steps for the Phoenix project, cut the budget to a possible amount and get every 3 month a new release:

let's think about the code sprint about the main idea. I think a code sprint should be prepared very well.
Additional, often things couldn't be finished on code sprint or the code review or the documentation is missing.

Lets think about something like:

Prepare the code sprint 10 days WT
Finish the code sprint 20 days WT

We have 120 days payed worked, to be sure things started get ready. Releases can be planned and in the time between we can see that community work is done. Hopefully through the year the community will get more an more active. We have a lot of marketing/press work which can be done to push the news on each codesprint in the world :-).

RE: Phoenix Development - Added by Felix Oertel over 6 years ago

Karsten Dambekalns wrote:

What is missing is a Project Owner for our scrum approach. [...] We have been looking for input and people around that topic for (literally) years. [...] it never worked out

No offense, but why did you hand in this application then? If there are that fundamental structual issues to be solved, IMHO paid development should be stopped and solutions should be found first.

RE: Phoenix Development - Added by Felix Oertel over 6 years ago

I support the idea of Volker.

What about a release team of three - four people. One responsible for each codesprint, but constantly working in a team. They could get some money to prepare the codesprints (agenda, quality assurance, infrastructure, etc) and also a budget to pay people to do unpleasent developing, given that the people in the release team are not the people getting paid for coding of course.

This should give us decoupled project management and developing und thus a quiet balanced feature list (because more people are involved) and paid development only, where it is really necessary.

RE: Phoenix Development - Added by Stefan Padberg over 6 years ago

Hi,

here is the Typo3 grassroots speaking: I am a single person Typo3 agency and looking on this Phoenix thing with increasing astonishment. In my point of view, the Phoenix project should be dropped. If somebody wants to go on with it, please go ahead, but no money from the Typo3 community.

The Phoenix is for me a completely different CMS. Why should it be supported by Typo3? All the small daily development work which was done by us in the last years, is completely lost if we want to use Phoenix. Far the most Typo3 extensions aren't yet based on extbase/fluid, so this alone is such a lot of work to do - for me it makes no sense anymore!

With the money for the Phoenix project we could do a lot of improvements for Typo3. I don't want the Phoenix be supported any longer.

I know many people in the Typo3 world who think like me. We want Typo3 to be the best! And to support Phoenix is not the straightest way to achieve this common goal.

RE: Phoenix Development - Added by Lorenz Ulrich over 6 years ago

@ Stefan Padberg:
Your statement is somewhat short-sighted. If you like to use "TYPO3 CMS" (v4/v6) for your existing customers, that will be no problem for the next years. (You can even stay with tt_news if you don't want to learn how "news" works... as long as it's maintainted.) But just the fact that you have to learn new concepts should not prevent progress.

If the new CMS (Phoenix) will be a success - and I'm quite sure in the end it will be a success - the focus will shift from TYPO3 CMS to this new CMS. More and more members of the community could then invest their time in this new CMS and someday (which won't be soon) TYPO3 CMS could be obsolete even if it's not planned like this at all. That's why I think that it doesn't hurt to adapt to the new stuff and use it where it makes sense (and maybe this new CMS won't make much sense for a site with one image and five subpages).

In my opinion, the "TYPO3 way of thinking" will not be lost at all with the new CMS: You will deal with Fluid, and that's what I'm doing with every website I'm integrating (FLUIDTEMPLATE, Fluid based extensions like news, powermail etc.). You will have a new version of TypoScript, you will have a pagetree, but you will also benefit from more advanced concepts in terms of content editing, image editing etc..

I can't share your negative thoughts about that, even if I see that there are quite some organizational issues to be solved on the way to this new CMS.

RE: Phoenix Development - Added by Stefan Padberg over 6 years ago

I thought like you - since it came to the decision to go on with old Typo3 as V6. I am missing a serious effort to come to an end on the side of the Phoenix project. Questions could be:
- What features are still needed to be compatible with Typo3 V4/6 including a smooth upgrade process for the Typo3 V4/6 extensions?
- How many man-hours are needed to fulfill this?
- etc.

But nothing like this. To give such an amount of money just for promises - no way!

The Phoenix project had some important spring offs for Typo3 V4/6 (i.e. extbase/fluid) - o.k. But I would actually prefere to advance the Typo3 Core along with the real needs of the community. This was the way Typo3 got strong. I would advise to go back to this realistic approach.

(1-25/36)