[Plone-conference] Openspace: growing plone | as a brand
djay at pretaweb.com
Fri Oct 24 10:18:44 UTC 2014
On 24 Oct 2014, at 4:47 pm, Peter Jacobs <Peter.Jacobs at kuleuven.be> wrote:
>> Namens Jean Jordaan
>> People aren't just slinging code, they're building a commons that allows
>> them to make a living in a good way: that includes meeting for sprints all
>> over the world, working together because of mutual respect and shared
>> learning from different cultures, contributing at their level of comfort or
> Very true and valuable..
> I have not participated that much, but have always felt very welcome!
> Also, there is some bashing and blaming on consultants In this thread, which I think is a bit over the top.
I don't think it's consultant bashing. I think what is being expressed is what I will be talking about at the Plone conference. Even the best developers find it hard to think like end users and so those deepest involved with Plone can find it hard, like all developers, to work out how to improve the user experience. I think Plone is in part a consequence of having a developer led community and that is no ones fault.
> We use Plone to provide a large service to our university, with the help of a group of very knowledgeable and cooperative consultants who care a lot about the community, and help us build up expertise so we can manage the system on our own.
> It seems to me that during the years people in the community have moved up from code hacker to consultant/service provider, which is a very logical step, and valuable for Plone. The only thing missing is new generations of young code hackers coming in to bring new ideas and challenge the status-quo?
Exactly; the problem to solve is why that new generation is missing and how best to find it.
I don't think it has much do with zope or pyramid.
I think it has to do with Plone being to hard for small sites such as their own blog or a simple wiki for their workplace or school. People who start small, often want to use the same thing for bigger and bigger sites and some of those people are skilled developers who will contribute and/or become consultants.
However I believe those people are unlikely to come from the python community. The world is different than when Plone first started when light weight frameworks didn't exist and someone already skilled at python doesn't need a CMS anyway. We have to look outside the python community and offer something new and better to those looking for a CMS.
>>> Unfortunately what is left at this time is a big pile of excellent but
>>> rapidly aging code (mainly in zope I suspect), that doesn’t invite people to
>>> play and experiment as much as before.
>> I'm not so comfortable with people easily labeling code as "rapidly aging".
>> The goal should be to write code that works fine for at least a decade.
>> New and cool should be quite irrelevant to systems meant to be relied on.
>> Is it easier to build bridges or dams or buildings, with all their physical
>> wear and tear, than to design code? (Might well be! Still, we need to build
>> reliable systems.)
> Totally agree, let's look at some code then (please correct me if I am wrong):
> is the code for a central piece of the WMS: the http-server
> based on: http://www.nightmare.com/medusa/ (in maintenance since 2002)
> It is excellent code that has lasted for more than a decade.
> But during the last decade ideas and concepts have evolved, and it is time for a replacement of these core building blocks, no?
> Is there any twenty-something who wants to dive In this code when they have many better alternatives?
> (WSGI would be a solution for this particular part, but development has stalled?)
> All in all, we are using Plone for a mission critical service, and it has totally delivered on its promise as a large enterprise WMS.
> It is a complex system, that can match complex requirements :-)
> But it is time to take a good look at the core engine...
If the problem is getting a new generation of plone consultants, and core developers, then is rewriting the very lowest level of code really the solution? A typical person introduced to Plone will likely want to do things in this order:
- create some content/setup users
- theme it. work with html/css
- if they have to collaborate with others, use sharing and permissions
- build a few mini apps in it. A form to capture some data perhaps. Maybe add some ajax to add interactivity
- if they work with other people entering content, perhaps make some changes to the forms to enter new content
Do we actually have to change the core of Plone, create huge amounts of work and backwards incompatibility issues and rewriting lots of existing features, just to make the above steps easier for that new site builder?
If you assume that the way plone the software is built IS the same way someone has to build a Plone site: then the answer is yes.
But I don't believe we need to make that assumption. My company currently builds all our sites (which are more complex than above), without touching zcml, WSGI, eggs, adaptors, buildout, or any of that. All the sites we build, a motivated customer or beginner programmer could build. And this is without the Plone community really trying to support this style of development. Imagine if we did, with our smarts, how smooth and easy it could be?
More information about the Plone-conference