[Typo3-dev] TYPO3 version 4.0.0?

[Daniel Hinderink [TYPO3]]

Hi Kasper,

Before i retire for today, some quick annotations:
 
>> Since this really is a marketing question, what exactly are the top five
>> features that you think justify this step in the eyes of customers?
> 
> We could go through the changelog and try to reflect over the last 15
> month. Currently I can't remember it all.

(biiig chunk of sensible stuff cut out)

> Big features:
> - DBAL foundations has been implemented
> - Charset support (UTF-8) [minor]
> - .....
> Smaller features:
> - Core is cleaned up
> - Code is commented.
> - .....

OK, we can start building some message around these for the websites and the
press work. One problem is, that DBAL has no meaning to customers in terms
of readily available functionality, unless there are DB handlers for some of
the key RDBMS's around.
It is like a car without petrol on the same island. So we'll just have to
wait until we've got at least Oracle up and running.

>>> 5.0.0
>>> - When some great, yet unknown feature arrives or we see reason to make
>>> the jump (can also be triggered by time alone).
>> 
>> Well, we can of course have jumps when big improvements have been made, but
>> i agree with Masi to rather divide the development strands have some things
>> scheduled for, let's say, version 5 and have the regular development going
>> on alongside on a fast paced but normally incrementing versioned strand.
>> 
>> I suspect there are several people who would love to hop on the version 5
>> train (e.g. For going PHP5 entirely) and just as many who are quite right
>> with staying with the main strand and improving on short term goals. It
>> would be a waste of creativity to not offer this possibility.
> 
> I think I don't understand your point.

Many projects are developed by different teams, like the Linux Kernel, where
one team is working on the next version and another team is working on a
version beyond that. This way fundamental work gets more time and does not
interfere with stability.

What i am suggesting is to have a discussion on what v5 could and should be
about and then have a team of people making it independently of what the
main strand of development is doing. It's like a fork within the project
that merges back into the trunk at a later date.

>> BUT all of this requires a general development roadmap! I am all for it, but
>> so far this was more or less out the question.
> 
> For me it still is out of the question. Make a roadmap for me and you
> emprison my programming soul. I'm not against goals generally though.

I am not saying you can not have your way. You are powering development for
the most part anyway, so it is all your decision and also up to your
preferences. I am only saying, that if we want to do certain things, we need
to plan a ahead in more detail. See below.
 
>>> I think this makes sense.
>>> - We will send a more clear signal about the development of TYPO3 which
>>> really *IS* ongoing and has been for years!
>> 
>> It might help, but I doubt version numbers alone are so very powerful a
>> communication signal. I think it also requires clear communication of the
>> achievements. In traditional software development this is easy, because the
>> management decides what to do and repares the product communication
>> accordingly. In our case, we have the todolist and the changelog and a knack
>> for surprises, which makes it very hard to communicate the novelties in
>> full.
> 
> I don't get this either.

I am trying to say, that giving versions some good looking numbers or names
is nice, but it is alone not very powerful. A version four, or five or X is
cool, if we a.) have the features that really make a difference to the
audience and b.) actually communicate these features.

You agree on a. but have to admit that we don't have an awful lot of exiting
new stuff for the people that put their money into TYPO3 (yet). In terms of
b. we have just started speaking about wether we could communicate 3.6.0 as
such, or as 4.0. In my opinion we should be discussing wether we have enough
cool news to justify 4.0. And in my opinion it is close, but not cigar
enough (yet) for making such a jump.

So why not clean up just a little bit and call the current code 3.6.0?
Is it really not mature enough? I think by constantly pushing it back in
time expectations rise, plus more and more features get added under the
hood. So you feel like it should really be more then 3.5 + 0.1.
Why not be quicker and expect less and release 3.6 now! and 3.7 in eight
weeks?

> We just increment version numbers when we *have implemented* stuff and
> see that a certain jump is justified. This seems like no problem for me,
> but if you want to predict/define what any given future version contains
> it is of course (due to the spontaneous nature of development).
> 
> When that is said, I actually DO have a more clear roadmap for what I do
> next than I have ever had. However I'm not going to publish that to
> anyone publicly since that would just hold me accountable for it - which
> has a very negative impact on my stress-factor.
> 
> 
>> In other words: spectacular version numbers alone, will not be pushing TYPO3
>> very much further. It will also need to be accompanied with a development
>> process that provides information in a way that has nooks and crannies for
>> communicating what the new stuff has to offer. You will have to make that
>> effort, i am afraid, since you are head of Development :-)
> 
> This I didn't understand either.

Same as above. Marketing needs facts from development that have real value
in the market place to end users and it needs to know them ahead in time.
(To tell you a secret: marketing actually is about finding what the end
users need and tell the developers about it, before informing the public
that it will be available :-)

> Do you think it is a big effort to justify version jumps?

I think we need a fat list of cool stuff that many people can actually use.
If that is not the case, then there is (sadly) little marketing value and we
might as well call it 3.5.1 for the sake of book keeping.

>I think that
> will be very easy since the jumps are based on exactly that: What
> happend since last time.

Right, but as stated above, may be smaller news could be used to push out
new versions.
 
>> 
>> AND it will need features that are really sensational in terms of satisfying
>> wide spread important needs.
> 
> This I didn't understand either.

Same as above: we need blockbusters to justify version jumps. If the news
that come with it don't rock my grannies chair, we should keep our powder
dry and wait for bigger news to call something the divine mind-blowing
version 4, with lametta, fireworks and marching band.


>> Let's try to go one step back and look at what we want to achieve:
>> 1. with version numbers as a form of communicating progress
>> 2. with development
>> 
>> The discussion about development goals should come first, because this is
>> where value for the customers is actually created. When we have settled on
>> some agenda, we can think of how to get there. When we know that and have
>> all of this settled, we can think of how to label it with version numbers.
>> 
> 
> I don't want to think forward.

:-) that is not true!

> I want to look at what has happend since 3.5.0, then I realize that with
> version 3.6.0 now it means that with this pace we are at 3.11.0 in 2010.
> Then I say "Lets increment a little more than this" and suggest that the
> jumps like 3.5 -> 3.6 are made in the first digit instead. This brings
> us to 4.0.0 instead of 3.6.0. And from that moment we will just
> increment with greater jumps (basically moving the digit to increment).
> 
> For the future we cannot predict anything. I would even predict that if
> you put up a development roadmap putting features onto version numbers
> it will not be followed in real life. Features come when they come and
> you will just have to constantly modify your roadmap order to reality.
> If that helps you, fine. But the version numbers are just not defined by
> it but rather by what actually happend.
> 
> Take DBAL as an example. Lets say that version 5.0.0 of TYPO3 was
> supposed to include DBAL and version 4.0.0 was defined by having
> versioning. Now, suddently we do have DBAL in version 3.6.0! So; will
> you jump to version 5 without implementing versioning? Will you insist
> that versioning MUST be done right here and now because otherwise we do
> not follow the order of the roadmap? Or will you just say "Well, DBAL
> seems to be enough to jump to 4.0.0. Lets put versioning on for 5.0.0".
> I think that latter case is just fine and what we will have in reality.

I was not saying, we have to have a roadmap and stick to it no matter what.
I was saying, that we have to have one, _if_ we plan to follow some path
with milestones that make sense to developers and the market alike. And that
is what is giving real meaning to the positive message of sexy version
numbers.

Everything else means going with the flow and making the best out of the
results. That is a valid and justifyable option, with many convenient
side-effects, like not having to make and keep promises, being open to
inspiration, generally freedom in all sorts of flavours.

It is just not as powerful as creating a situation where true collaboration
is possible and everyone can prepare to be in his position on day x to do y.

Obviously TYPO3 is also benefitting from the way things go and being very
much centered on your pace and practice. I honestly don't know if there is
an alternatve at this point either.
It is a complex choice and i don't promote radical change, i just have
strong doubts about the marketing power of making version jumps without
enough of the justification and preparation for such a step.

It's as simple as that. Ah and almost no fun in that one too :-)

Bon nuit,

Daniel

-- 

Daniel Hinderink
TYPO3 - get.content.right
Innovation, Marketing, PR
http://www.typo3.com

-- 
It is a fine thing to be honest, but is also very important to be right.
Winston Churchill on S. Baldwin