[TYPO3-hci] Motivations, WAS: 4.1 = menubar/iconbar/dashboard; lets go!

[JoHasenau]

Kasper Skårhøj wrote:
> Thanks JoH  ( :-) )
>
> Caught me a few months back, I would agree. In the meantime I
> realized what healthy Open Source is made of:

Something like "healthy open source" as such doesn't exist.
And there are tons of different flavours, concepts and behaviours that could
have people do things completely different from your point of view, and the
result would still be called "healthy open source".

> Lets assume we have a 90-10 balance (probably worse) between
> stakeholders and actual contributers to usability on this list (and
> TYPO3 in general). Here are two strategic scenarios:
>
> 1: "OK, lets hear everyones opinion, then decide on a solution and we
> will find someone to implement it".
> This is such a nice and comforting thing to hear for the 90% that
> hopes to get their problems solved by someone else. But it seriously
> wears on the 10% contributers who will rightly ask, why they have to
> do all the work they have no self-interest in.
>
> 2: "I don't care - for me it works"
> This is very disturbing for the 90% stakeholders who now realize that
> if they want it to work for them, they have to be _active_ with more
> than ideas to get their agendas through. For the 10% contributers
> their motivation will stay intact because they can improve the
> software for their own needs - and will do so next month again.
>
> Scenario #1 will by time shift the balance from 90/10 towards 99/1
> while Scenario #2 will shift from 90/10 towards, say, 80/20 or better
> (or the project will get "cleaned up" to a 100/0 balance because the
> 90% gets mad and leave).
>
> "I don't care - for me it works" sounds quite negative, but the sum
> of such claims is very positive as long as everyone has a fair chance
> to make it work for himself; and that is where I want to go because
> it is the very rationale behind why Open Source works: The Personal
> Itch. Watch my keynote podcast next week where I discuss this in more
> detail.
>
> I will therefore claim that your understanding of a "professional"
> and well working Open Source community is not on the mark and that my
> view is a more healthy way to lead our efforts.

And this is where you are on the wrong track, since you are still making the
same mistake that is a so well known behaviour of many open source coders.
The only thing you regard as "contribution" in this context is coding.
But all this coding is pretty useless, if you haven't got a good concept or
if you simply are on the wrong track.
There are many people especially in groups like ECT or HCI, that are not
even able to write just one line of code, but still they have a lot of
important things to contribute.
Their major advantage is, that they don't see things from an "I don't care -
for me it works" point of view, but have a bigger target group in mind.
They are able to take a step back and get an overview of the whole concept
and the influence it might have on other parts of the system.

I already wrote this in another thread, but I would like to repeat it here:
1. There has to be a concept about what you want to do (i.e. create a
menubar).
2. Then there have to be ideas how to create a solution for this task. (i.e.
AJAX)
3 .Then a decision has to be made, which way to go. (i.e. clientside JS)
4. The last thing you need is the real code, and you don't need special or
gifted people to write it, because (sorry to say that - but it's a simple
fact) you can find a coder that is able to translate a good concept into PHP
code just around each corner.

You might have noticed, that there are lots of other tasks to do than just
simple coding, and therefor you need lots of different contributors that
will be simply offended by a sentence like "I don't care - for me it works".

In your scenario you completely skip the steps 1 to 3 and throw in the
result of step 4.
And even worse you tell the people that would have contributed to step 1 to
3: "If you don't like it, change it! - And if you are not able to change it,
shut up!"

This is nothing I would call "healthy", it's just a simple overestimation of
the importance of coding - but this is not a special TYPO3 related problem
but a problem of many open source communities.
The result is a piece of software that will work for all its developers and
people that are on the same skill level but will be partly (or completely)
useless for the rest of the world.
If this is what you want to achieve, you might be heading into the right
direction, since your way of doing things will of course be much faster than
mine.

> The TYPO3 Association offers you these ways to contribute:
> - Writing patches that are approved by members of the core team.
> - Extensions for anything you cannot get acceptance for in the core
> team.

Again this is just based on simple coding.
As long as you can't code none of your concepts will make it into the core,
since there is no patch that could be approved.
This way you are missing a lot of good ideas and concepts that would beat
the pants off the current system.

> For me, its no more, no less. Since this is foundational theory for
> me, I would like to hear if you find major problems with it.

Fortunately it's just a theory, since this means it can be improved ;-)

> As for the HCI improvements to 4.1, I always said this was my
> _suggestion_, I have suggested my code as a _prototype_, invited
> people to _improve_ it, but if no one will contribute significantly
> on the _code_ side, you get what you see now.

Would it make such a big difference, if you would accept to realise other
peoples concepts, even if they can't send you a diff or a readymade piece of
code?
I mean: Would it be such a big difference regarding the _real work_, or
would it just be the difference, that you would not be the inventor but just
the "workbench"?

Could you imagine this scenario:

Contributor:
    "Hey guys, I've got an idea how we could create a really cool menubar.
    We already discussed that in the ECT team and now we need someone
    to write the code for the solution we choose."

Developer:
    "Cool. I will try to help you with that, since I know you are not real
coders.
    I have something else to do, but I think I can deliver someting within 4
weeks.
    And thanx for writing such a good concept. It will save me a lot of
time."

I know this almost never happens, since most of the developers will react in
a completely different way:

Developer:
    "Never ever. I have enough to do maintaining the core code. So as long
as
    you don't pay for it you will have to live with the solution XYZ I have
provided."

And this is where it starts to get ridiculous, because the concept and the
coding of solution XYZ sometimes took the developer months of _unpaid_ work.
At this point it doesn't matter anymore, if the new solution will be better
or not. (In fact it wil be even worse, if the new solution beats XYZ)
It's just a matter of "if it's not my idea you have to pay me for coding or
do it yourself - and if you send me a diff I might think about implementing
it".
Sorry, but this behaviour is just a waste of time and resources.
I have to write the code, create a patch, send it to the dev-list just to
get informed about the fact that it would _not_ be accepted??

It doesn't make sense to discuss a piece of code after it's already been
written, you should do that before you start coding.

So this is my vision of "healthy open source" - and you see it's a bit
different from yours.

There are inventors, creators and workers, and sometimes people are a
combination of these types.
Very few people are a combination of all three which is called a universal
genius.

In my scenario there's a team of all these types, lead by a UG, in your
scenario there's only room for UGs

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.cybercraft.de
T3 cookbook: http://www.typo3experts.com