[Typo3-dev] The Right Crew

[Kasper Skårhøj]

Hey Sander,

wow, long mail. I got through it but can't comment on every point. I'm happy
to see that you find positive aspects and think you hit the nerve we are
already focusing on which is about the overall leadership and not the
volunteers. But as I said I feel utterly incapable of doing anything about
leadership myself except leave it over to someone else. So who is our
"Director"?

- kasper

Sander Vogels wrote:

> 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

-- 
Kasper Skårhøj