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

[Kasper Skårhøj]

Hi JoH.

What a nice chat. It's fun!

>> 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".

Our culture arose from pure personal itch. Our variant of Open Source  
doesn't have a company backing as others do. Assuming we want to work  
along that culture, a healthy state is one that gives the highest  
incentive for everyone to get code done. I want to move 90/10 towards  
80/20.

>>
>> 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.

It doesn't matter what you or me regard as a "contribution". But it  
matter, that no one can earn the right to impose obligations on  
others unless they have specifically agreed to that.

On the HCI list people can contribute insight into usability, but  
such insights will only make it through the last link in the chain if  
they grap the heart of a coder who believes in it and makes it happen  
in lines of PHP.

Challenge: How do you suggest we motivate our core developers to  
implement a set of usability-dictates from this team?


> But all this coding is pretty useless, if you haven't got a good  
> concept or
> if you simply are on the wrong track.

A developer solving his personal itch never miss.


> 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.

Exactly; They have personal itches as well. Since they cannot code  
themselves, they must be creative. They can team up with coders who  
will care for their problems. They can offer any motivation between  
money and the promise of sunshine next week, but its up to them to  
figure out.

I'm encouraging proactivity here.

> 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.

No, they don't. They have their personal itch in mind (long-term or  
short-term). They want their own clients to be happy. If other  
peoples clients can be happy too, that is a nice win-win.

> 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.

There will be different ways to look at this. Surely, Elmar thinks we  
are bombed back two years by choosing a pragmatic approach to AJAX  
using a library like prototype to get something on the streets by mid- 
november. I don't. For me its more important to try something new.  
Code doesn't matter in this case, the knowledge from the experience  
does.

>
> 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.

I disagree. We can take more gradual steps. We are a bazaar, not a  
cathedral.

>
> 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".

You are right. To finish my concept, I need a graphical designer. And  
some usability testers. I'm already working on this.

>
> 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!"

Straight talk, but you are right. So maybe someone who likes your 1-4  
step model should get going and prove you right. I just don't feel  
motivated by your approach.

You have equal opportunity as me. Like anyone else, I will kindly ask  
the core team for their opinion about letting my work into the core.  
If they say no, I will just make an extension out of it. I will not  
go against a majority vote since I want to respect the current  
userbase of TYPO3 and their wishes.

>
> 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.

Correct. Meet TYPO3. Usually TYPO3 gets either 5 stars or no stars  
when rated, but you rarely see it get 3. Simply because either it  
appeals to or repels people.

Btw, when did "personal itch" motivated developers ever claim they  
were making software for the rest of the world?

They make it to solve their own problems, to make money (clients  
problems), be famous (those might listen to you!), be idealistic nice  
guys (they might also listen, but will burn out some day).

> 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.

Who wants to beat the pants of current systems?

The only question I'm interested in is; What barriers currently exist  
that keeps people from scratching their personal itch? I will  
dedicate my leadership of TYPO3 to lower those barriers so everyone  
can seek their opportunity. I will not dedicate my leadership to  
scratching the itches of anyone who randomly passes by. Been there,  
don't that - for too long and with too heavy personal implications.

(Again, this is a complex issue and my keynote addresses it with a  
more balanced expression).


>
>> 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 ;-)

I wonder if anyone will counter that personal incentive is the  
strongest motivation for any human being?

>
>> 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."

Oh yes, we see those scenarios all the time! They never work. Then we  
try to push the moral bar but it doesn't help. We have been  
completely mistaken for years, simply because we haven't really  
grasped how impossible virtual volunteer teams are. Not to mention  
big-bang-goodbyes from people who resign in complete disillusion. I  
want this idealistic madness to stop and get real instead; The only  
thing that consistently gets things done in our community is personal  
itches.

However, that doesn't keep us from being nice guys.

Again this is communicated much clearer in my keynote. Podcast on  
monday.

>
> 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."

Yes. Of course.
Pay him. Or find another core developer. its not a closed circle. We  
have a bug-tracker for patch contributions. There are millions of  
people able to feed useful stuff into TYPO3 and we need more, which  
will come if you begin to think out of the current box of 20 SVN  
committers.

See my question on removing barriers for contribution. This is the  
key question.

>
> 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??

I don't get it. Patches do get accepted, don't they?


>
> 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.

I find it easier to relate to actual implementations. I'm not as  
abstract minded as others. There are different preferences here.

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

Yes, its different. I don't see how it can be effective. It's a high- 
cost up-hill movement while I'm suggesting everyone to freeride down.

>
> 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

Use your imagination and there will be ways for a non-coder to get  
things done. If you can't imagine that, maybe its because we have had  
a service-culture for years where people have gotten used to expect  
that their feature requests were taken as commandments by the  
development crew. Consider that era ended now.

There is no public service.

- kasper


"Necessity is the mother of invention"
-------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |  
gizmo: kasper_typo3