[Product-Developers] Re: How can we win the battle for developers?

Dylan Jay gmane at dylanjay.com
Sun May 11 05:22:14 UTC 2008


Ricardo Alves wrote:
> Dylan Jay wrote:
>> Gilles Lenfant wrote:
>>> And the learning curve of Python + Zope2/3 + Plone is about 6 months 
>>> for a good newbie. And Plone 3 added about 1 month to that learning 
>>> curve - compared with Plone 2.
>>>
>>> I think that one of the goals for Plone 4 (5?) should be to cut this 
>>> learning curve to 4 months, this should really attract more people to 
>>> Plone.
>>
>> Yep. It would be great when skins and form controllers and python 
>> scripts never have to be learnt or considered.
> 
> So, what would be considered? XML and ZCML? Are we still talking about 
> how to "win the battle for developers"? Developers tend to like to code :)

I'd prefer zcml z3 browser views IF it was the only thing I had to learn 
to customise plone.

> We have a big application stack. Making easier to extend Plone without 
> the need to learn the the whole underlying technology is good, but only 
> as a starting point. Developers eventually need to understand the magic 
> behind-the-scenes. And the more we hide it, the more magic and hard it 
> will look like.

Exactly. Hiding technology with simpler but less flexible technology 
isn't the answer. Perhaps the answer is reducing the size of the stack? 
So the number of concepts needed to understand the full stack is less.

>> Plones high learning curve is caused by too much choice of ways to do 
>> things IMO. We need 1 or 2 ways of doing things at most. and if there 
>> is more than one way they need to have a very clear reason why and 
>> when you use one or the othe?
> 
> This is true. For example, CMF skin layers vs browser resources, views 
> and layers is causing lots of confusion for newbies.
> 
> But that's caused by one of the characteristics I love most about the 
> Zope/Plone world: the unstoppable technology improvements that make the 
> code base bleeding-edge all the time. If we hadn't made the move for z3 
> style code, for example, we would still be only using old z2 style 
> products, with no benefits from the z3 component architecture, and plone 
> would probably be dying, while some other projects would be rising on 
> top of zope3...

I do agree to innovation is a great thing and that moving to z3 is a 
great initiative but...

> On the other side, we must ensure backward compatibility with the 
> old-style code in a sensible way (IMHO, a software project can't be more 
> disrespectful with its users then when it breaks compatibility with 
> older versions).

Well I guess herein lies the problem. Its a three ways tussle between 
innovation vs backwards compatiblity vs reduced complexity. It seems try 
to solve one and the others suffer. But does it really have to be that way?
Some questions that come to mind are:-
Are we kidding ourselves with backwards compatibility? There aren't many 
addon products, skins or other customizations that don't have to be 
upgraded to work with plone3. All my sites need to be modified. And if 
they are modified even a little, in some sense I'd rather spend the time 
rewriting to work with the new technology... if it was not going to be 
obsolete in the near future.
Take for instance portlets. I had to do my first plone3 style portlet 
the other day. It seems that formlib is the prefered way of doing forms 
with portlets so I took the hit and learnt formlib. But how long is 
formlib going to be around for? Will learning formlib help we with 
coding other parts of plone? Now there is z3c.form. Will I need to learn 
that by plone 3.5?
This is an incredibly difficult problem to solve I know. and perhaps 
thats why its easy to dismiss and put it in the too hard basket. We have 
many different people working on plone. The really productive ones 
already know all the technology in the stack, when they know there is 
create new technology they can bring in to solve a problem (like 
z3c.form) then who is going to stop them?

> Don't get me wrong. I agree we need to make Plone more attractive for 
> new developers. We just should be aware that some of the aspects that 
> make Plone difficult/complex are motivated by some of the principles 
> that drive the community and its development approach.

but what I wanted to raise awarness of is that I think too much 
innovation can kill plone as much as too little.
We could be driving forward but leaving everyone else behind. The more 
technology we introduce without replacing and COMPLETELY discarding old 
ones, the harder we make it for developers to join and help us and 
eventually we run out.
Is it a goal to get rid of old ways of doing things like form controller?
I think an excellent goal would be to make martins book half the size it 
is today. I suspect if another version were released to today it would 
have to include more chapters rather than less :(








More information about the Product-Developers mailing list