[Typo3-dev] The Right Crew

[Sander Vogels]

Kasper Skårhøj schreef:
> Hi Guys,

Hi Kasper,
> 
> Thoughts kept buzzing around in my head this night and finally forced me to 
> get out of bed early :-(

Dude, count your days lucky, this will be normal as soon the kids hace 
arived. Tomorow 6.30 daddy has to be present! ;-)


First a short background; I'm not a developer at all, I cannnot write 
one line of code. I've been in strategic product development, marketing, 
customer relations and the lobbying and networking of TYPO3 now for five 
years. I'm in the mrketing group of TYPO3 because I think it needs a 
customer perspective in development. Personnally I find the marketing of 
TYPO3 a simple task, its quiet easy to convince organisations, 
companies, cities, governments and even the military to use the system. 
Sure we did put lots of efford in it but still, without a large 
marketing budget TYPO3 became ECMS market leader in the Netherlands 
within a few years and over 100 companies make a living of it.
So how can a CMS with a core that some say isn't up to certain standards 
gain this dominant position?

Thats because all these organisations look at TYPO3 as customers or 
users who need a product that fits their needs on an information 
perspective. The people who make the decissions are not into neet OO 
code, most of the time they don't give a sh..

Functionallity of most software products always comes first in the real 
world, the way its' programmed second. I can point out to all developers 
here that this is why Windows became so dominant. It was user-friendly, 
made a pc cheap and created a platform were developers could create 
functional programms for easily. Altough the code stinks up to this very 
day!
So should we have no concerns of how our code looks? Ofcourse we should 
have these and ofcourse we should improve it. Yes we might even in some 
future rework the complete Typocore to the desired standards. But is 
this reason to great worrying at the moment? Well from a customers 
perspective it isn't. TYPO3 is doing quit well what people want it to do 
and we have lots of time to redesign parts of it or even the core if you 
like.
This whole discussion is not new btw, it started already in the US in 
the seventees ultimating in a famous essay in te Lisp community in 1984 
called 'The Rise of 'Worse is Better''. You can read it here: 
http://www.jwz.org/doc/worse-is-better.html
What I always have liked is the conclusion of the author;
'The lesson to be learned from this is that it is often undesirable to 
go for the right thing first. It is better to get half of the right 
thing available so that it spreads like a virus. Once people are hooked 
on it, take the time to improve it to 90% of the right thing.'

The people of the Lisp community didn't agree and see where it got them. 
I do agree a great lot with this and think that this is exactly the case 
with TYPO3. We're half-way in development of the for 90% perfect thing 
but in the meanwhile its spreading like a virus. And once infected 
organisations using it will only benefit from our improvements.

 >
 > CONCERN:
 > A true concern I have is this; How do we channel all the great 
resources from
 > the TYPO3 community into a unified effort on the development of TYPO3 
which
 > does not compromise the quality or impose great levels of overhead.

1. as soon as you are aware of a problem and start thinking of it, 
you're already half way.
2. I ask myself or this can be done. Can you organise a large scale 
coordinated efford on development of a product which already has become 
so huge without overhead? And is this unified effort even neccessary or 
can the chaos theory also be projected on an open-source project?
In my opinion such an efford can only be done with a tight structure 
with corporate kinda hierarchy which is not wishfull on a open-source 
project. Some month ago I read the study on open source projects from 
Matthias Stürmer which included input from Daniel on TYPO3 
(http://opensource.mit.edu/papers/sturmer.pdf)

This study again made me feel very comfortable with the open source 
project I'm in. But it also made me think again on the issues of 
commitment and dedication that you are refering about. My first 
conclusion would be that voluntering for community work and open source 
development is something that needs fresh blood all the time and you 
need as much as you can get. And this email of yours is the first that 
I've ever seen that points to this direction. But you talk about which 
profile people shoud have while I think first you should wonder if you 
and the rest of the core-team have been open for this until this very 
moment. Over the years you guys have astonished me with the output you 
have and I have always been amazed how you hold up to it. So it should 
be fairly normal after such a long period of intense work combined with 
the super large system it has become, that you extend the core team to 
10 or 15 people. I think this is what is needed to stay up with the 
demands within the market the next three of four years. (and who even 
wants to look further then such a period?). This enlarged team should be 
close cooperating with the marketing team to get the input form the 
markets and so guidance to development on functionallity as much as on 
clean code. (btw the team members would also have a lighter job to do)
This team should, each within its own base, communicate with the rest of 
the community for input, to get a basis of agreement and to get people 
helping with sidetracks like documentation and bugfixing but also the 
communication to the 'outer world'.

Now comes the fun part; in theory this is what we already have planned 
to do to some extend. The founding and structure of the Associotion and 
its relation to the community is the beginning of this. Yes we need more 
people on board, we need fresh blood, we need to listen to fresh ideas 
and we really should listen to oneanother and act upon the things we 
agree on. But we're already half way and that is enough for now or at 
least no reason for you to get out of bed in the morning. (side-effect 
is that we never get Kasper juniors this way)

For the future I have some ideas that tackle your concerns. This in 
response of the rest of you email.
> 
> I need your help on the answer, but to prime the ground I will tell you about 
> how I see myself and evaluate my personal skills as crucial for the success 
> until now. This is NOT to be seen as a defense speech for what I have done! I 
> don't need to defend any of it and I'm pretty proud of TYPO3 including its 
> quirks. 
> 
> BACKGROUND:
> As the initiator and chief developer of TYPO3 I think I possess at least three 
> key criteria that were necessary for this role:
> 
> 1: Vision
> 2: Pragmatism
> 3: Stamina
> 
> Vision: I have been visionary about concepts that solve realworld CMS problems 
> (TCA / TER / TemplaVoila / TypoScript / ImageProcessing / Workspaces etc). I 
> have also been visionary about the architecture of procedural programming in 
> a language like PHP although unorthodox at times and not classic OOP at all.
> 
> Pragmatism: I have been willing to compromise when the degree of importance 
> fell below a certain limit in order to actually release working code. I never 
> believed that my code could not be improved, but I did believe that if I kept 
> circling around in constant obsession with architecture I would not serve the 
> overall vision.
> 
> Stamina: I kept going and going and going. I realized that to be successful I 
> would have to concentrate on TYPO3 at the expense of business opportunities, 
> education, other interesting areas of the web and the distraction that awaits 
> around every other corner in life. Many times the grass has looked greener on 
> the other side, but without my discipline of commitment TYPO3 would not be 
> what it is today.
> 
> Now, what happens if I lacked one of these:
> - Without vision there would be no product of interest.
> - Without pragmatism the vision would be in alpha-state for eternity.
> - Without stamina we had raised a tombstone back in 2002

This are in some way the same labels management books use as the basis 
of a succesfull corporation;
- a creative chaotic visionair that forsees the future and thinks of all 
kinda products that can be developed
- a director that filters these ideas and brings them into real life 
products
- a worker that ensures that te work is done and delivers the product to 
the consumer.

So what you point out is not only the framework that is needed within 
people for development of the product, it are also the main roles that 
our organisation, The Association, should fulfill.
This is why its also important to involve marketeers and communicators 
into the process.
I find it perfectly acceptible if most programmers ony have pragmatism 
and endurance, but the vision is something that should be a joined 
efford. As a programmer you need vision if you want to create new 
programming language because you have to be able to forsee wat you could 
do with this language. Like you have forseen that with typoscript, we 
would be able to endlessly tweak TYPO3. But as soon you have the 
language all kind of business professionals can be able to envision a 
great product.
> 
> 
> THE RIGHT CREW:
> Does every member of our future TYPO3 crew need all of these skills?
> 
> Vision: Not everyone needs to be visionary, in fact only a few might be 
> preferable. I don't think visions are our problem. Maybe it could be a 
> problem to agree on which visions to follow. Yet, a more serious problem is 
> how the visions of functionality and code architecture can be adopted by 
> those who are going to implement it (if we assume they are not necessarily 
> the same as the visionaries)?
> 
> Pragmatism: One a continuum from visionary-coder-releasemanager the visionary 
> could do with almost not pragmatism, the coders would have to live with a 
> mixture and release managers must be very pragmatic. The interesting focus is 
> the coders in the middle, because their responsibility is to make sure things 
> are working today and tomorrow but in the long term pay attention to the 
> visionaries direction. How can this be implemented in a way that doesn't 
> break backwards compatibility between each release and at the same time is 
> inspiring to coders?
> 
> Stamina: This one is - unfortunately - necessary for every link in the chain. 
> To build anything as teamwork it is critical that every team member can be 
> trusted to carry his part to the end. The unfortunate thing is that most 
> people involved in volunteer work think that they can feel less committed to 
> the cause because they are not paid and usually prioritize their paid work 
> and opporties higher assuming that everybody will understand. Maybe others 
> will understand but it just doesn't solve be huge problem it creates: When 
> people are constantly running in and out of volunteer commitments it 
> generates huge amounts of wasted overhead in the form of training, social 
> investment etc. in the team! The impact on the volunteer context is even 
> worse than for a company because a company could pay someone to deal with 
> such overhead while in the volunteer context it is OTHER volunteers who waste 
> their time on training a new volunteer that just disappears a few days, weeks 
> or months after.
> To make matters even worse for our online community it has been the general 
> experience that people slip out even easier because they don't risk to face 
> their abandoned team bodies in the local supermarket.

With the last point I dont agree. Yes its true that people run out of it 
all the time. But the tendency in your words is that this is because 
they don't have the stamina for the job were I think that you might 
wonder if the attitude of the core-group has been very open for these 
people. One should always start to look if you can improve yourself 
since you have more control over this then over others.
Another thing is that on a certain level there was a complete lack of 
direction within the project or some sub-projects. This is not 
somebodies fault, this is just a growth problem of a product thats 
maturing big time and we should tackle this problem.
So we should not start loking how the right crew can be formed but first 
how we create an environment where people thrive and florish. This 
environment will be the perfect soil were we grow our talents and 
organise it further into a great product (that's 90% perfect :-))

So I fiercly applaud on your current efford to open-up to the community 
this way. We're gaining another 10% at least towards improvement. The 
structure has started and the discussion is open, this makes me very 
happy indeed.
I also think that a list thread is not the ideal instrument for a 
discussion like this so maybe we can have a session or two during the 
next snowboard tour?
> 
> 
> How, people. I'm sure you all have great intensions and plans for version 5 of 
> TYPO3 and I'm all excited about discussing them. But how on Earth can we make 
> sure that such a discussion is not just another play with verbal buzz-muscles 
> that wastes time that could have been fruitfully used on practical coding? 
> 
> How can we make sure there is a crew to make it happen at all?

Conclusion: better direction, better structure, more openess and room 
for creative and wild ideas, brainstorms and last but not least; 
changing of roles.
I'm a very frontfighter of chanching roles lot of the times, for example 
to let membership of the Associations' board and General Assembly 
roulate every two years or so. Not just for democratic reasons but also 
because voluntering is something you cannot do all the time, you have to 
spend some time to build you own life and come back again. You can still 
contribute but in a well organised structure others can take over part 
of your job sometimes so you can refill your energy. For the rest leave 
the management, marketingcommunication and back-office to people who 
enjoy doing that and we're set!

Well, how was that for a starters? :-)
I'm sorry but I won't be able to response on replies before after the 
weekend since I'm off to the German marketing meeting.

Ciao,

Sander Vogels