My talk at PyCon 2008 is now up on youtube. I only had half an hour, which was tricky to do, but made the talk better and less chatty. Probably the best version of the talk, although the five minute version at  Plone Strategic Planning Summit 2008 might be almost as good.

Listen to it while looking at the slides. I should make a version of this that goes “bing” everytime you should move to the next slide.

I should use the words “fluffy cloud learning curve” more.

A couple of weeks ago I discussed the possibility of having a component registry browser with some friends. I mentioned this and also tools like ZMIntrospector to people at the Plone Strategic Planning Summit 2008 (others may have had the same idea, the process during the summit was such that it’s pretty much impossible to assign blame for ideas to anyone specific, so if somebody else also brought this idea forward: I’m not trying to steal the credit ).

The summit deemed it a good idea, and I was assigned as a champion for the task of creating a Plone Inspector tool. I might possibly have somebody lined up to do this as a project for the university, which seems great. I’ll come back with a time line in case he accepts.

Waiting for this, I’m gathering requirements. What does people want it to do? My requirements were the following:

• A component registry browser, to more easily see why your adaptations and lookups doesn’t work as expected.
• An object introspector like ZMIntrospector that works for views, so I can see what the attributes on a view is.
• It should if possible be pure zope3-code, so as to work both on Grok and Plone. (Tall order, I know).

Martin Aspeli also came up with this feature list (there is a bit of overlap):

• The tool is completely disabled in non-debug mode and is available to the Manager role only!
• When invoked upon a particular browser view, show its name, where it is defined, and what context and layer it is defined for. Ideally, it should be possible to generate a short code snippet that shows the view registration in full so that it can be easily adapted for a customised version.
• Similarly, display detailed information about all viewlets visible on the view where the introspector is invoked.
• When invoked directly upon a content object, show a class inheritance tree, with docstrings for public methods ala the DocFinderTab. Ideally it should be possible to drill down to view actual code.
• Similarly, display the views and viewlets that are registered for this context, in order of specificity (general views come last), with full information about how these are registered.
• Similarly, display any other adapters that are registered for this type, in order of specificity, with full information about how they are registered and which factory is in effect.
• Where appropriate (when displaying views, viewlets or portlets) it should be possible to invoke the portal_view_customizations machinery.
• Provide a context-less view that can browse all adapter, utility and event handler registrations. This should group registrations by interface and separate global from local components.
• The views that make up the tool should provide some viewlets so that third party products can insert their own introspection tools where necessary. For example, plone.app.portlets should do this to make it possible to view portlet registrations alongside view and viewlet registrations.

We can so far see a couple of main areas, with fuzzy delimitations:

1. A component registry browser/searcher.
2. An enhanced DocFinderTab/object introspector that also shows object attributes, registered adapters and possibly even code.
3. A view introspector that shows view information and viewlets.

In any case, work will start out with part 1 of this, and hopefully later expand in to the other areas.
So, what are your requirements? The more idea we have, the better this tool will be. No guarantees that we will implement it, though!

The Plone Strategic Planning Summit has been a great experience! (see Martin’s blog post for a debrief report)

It has been amazing, amusing and challenging a lot. In fact we did in incredible amount of work which unfortunately I don’t know how to use, yet. All of the main questions that I had before the Summit are still unanswered… and that’s the way it should be!

In fact the Summit has been a first step, an approach, a kickoff for in a very difficult path: strategy of an Open Source Project developped by an Open Source Community.

Thus the very first outcome for me is the motivation I received to start this blog and possibly renew my involvment in the Plone Marketing.

In fact after the Summit I feel the questions on Plone Vision are even more important than what I thought, and the answers more difficult to share than I expected, while on a shorter term Plone will nontheless benefit from the tasks & champions actionable results.

A big thank to every person that made and made-possible this event.

As was mentioned in Chris’s post the end result of two days of brainstorming, synthesizing and story telling was the assignment of “champions” or “proxies” for getting our whittled down list of initial priorities “out of the gate”. Rather than an amorphous blob of “sure we’ll get to this…uhhh.. someday” we sat in our circle (and yeah.. we twinkled.. californian’s do twinkle) and started the most important hour of the entire weekend.

There is no way in h-e-double-toothpicks (my 10 yo might run across this on the web.. can’t be too careful) we could have addressed all the topics that came up during brainstorming, synthesizing (sticky dots.. basically a visible way to put +1 on each topic) and story telling. This was not a decision making exercise.. this weekend.. it was an “ok, look, we have a lot of issues out there.. let’s figure out our audience, pin down their needs and get started on the ones we can address in the near future.” At least that was my impression. No way we can possibly represent the entire community but there was an even amount of “consultants/integrators to developers” and one of the turning points.. “at least for me” was when Alec Mitchell pulled me into his work group today to discuss possible TTW content type creation and seemed sincere in wanting to disseminate what would be a dream situation for the integrator.

On Saturday, I had been invited to participate in an Integrator’s panel with the likes of SteveM (moderator), Matt Bowen, Jesse Snyder and David Glick (OneNW).

I was the veteran having started using Plone in 2001.. pre-1.0 actually.. we had used Silva previous to experimenting with Plone.

Although a veteran I managed to avoid learning how to program but I have implemented many Plone sites.  The learning curve for a non-programmer/designer/integrator was steep to begin with and then with the current changes (after I’d gone and learned how to create file system theme products) created a whole new set of things for me to learn.
I was a little miffed.. honestly.. and frankly being told.. just use paster..just use buildout only made me feel like I was on the outside looking in.. after all the years committed to learning best practices and I was finally doing it right (and then it changed? ouch)!

And so I sat there in front of everyone and I felt.. relief.. ok so now you guys know and you are listening. The best part? I’m not alone.. this is not me standing on a pulpit all by my lonesome, crying over the fact that I have to do a little work… there was a strong “theme” (sorry) amongst integrators/consultants that creating a Plone look & feel is hard.
Take a look at http://plone.org/products and you’ll note the lack of themes.

The ability to say, “hey we really love Plone, but let me tell you about our experience.. ” well it was powerful.. to say the least.

My overall “attitude” has changed since day 1 of this event. I walked away today with the following:

1. I committed to Champion(ing) the Integrator Story. Acting as a liaison of sorts, reporting back to integrators and getting a feel for the pain points (not just mine). What this means is I’ll be focusing on bringing in more Integrators like myself to participate in testing of pre-releases and provide feedback.  It tends to be the same people testing bugs and reporting back.. we need “real world” integrators to test with client sites (especially migration) and let the dev team know what breaks.. and what works really well.

2. I’ve committed to learning Plone 3 theming and quit whining (partly because of the 14 yo rock star that showed up on our last day and proved that maybe.. the fear of the unknown has rendered me frozen in 2.5 theming purgatory..although I do like the 2.5 way to theme at the moment) Granted I have to “unlearn” some things that I’ve gotten used to but I can live with that.

3. I’ve committed to start creating 2 minute screencasts for TTW customization..(thank you Nate Aune for your commitment to “teaching” us how to create screencasts)
I think my first one will be how to change the Plone logo TTW

4. I’ve committed to learning more about deliverance (it’s still got some way to go but it shows tremendous promise)

5. I’ve committed to learning how to play darts (killer) better so next time I’ll beat Mr Baekholdt (I almost won!)

Plone Strategic Planning Summit 2008 was a fantastic success and I’m looking forward to PSPS 2009!

Peoples thoughts and experiences of the Plone Strategic Planning Summit 2008 is starting to drop in to the blogosphere, and just like the rest I had a great time. If there is just one reason to use Plone it’s the amazing community. If commercial software companies wine and dine the customers, we give the customers a yearly excuse to go to the best conferences available: The Plone conferences. In that respect, the summit was just what I expected, loads of great people having a great time, and coming up with great ideas.

In other respects, it was exactly what I did not expect. I expected a small conference where a plan for the nearest future of Plone would be decided. It was nothing of the sort. Instead, we were during three days exposed to what was referred to as “secret Google technologies”. That label was tongue-in-cheek and almost completely incorrect, as they were neither secret, Google or technologies. These techniques instead involve large measures of self-adhesive paper in various sizes and colours, and markers also in various colours (and scents, but that’s optional). These were used to great effect to let everybody know roughly what everybody else’s opinions were. And this is what the summit was all about: Communicating everybody’s ideas and opinions to everybody else, so that we could see which of all our ideas and opinions that had a general support in the Plone community.

Why is this important? Plone is not a democracy, were one community member has one vote. It’s also not a meritocracy, where people who have shown themselves worthy get to decide where Plone goes. Instead it’s a “do-ocracy“. It is the one who does the work that decides how it should look. If you want something done, you do it. Not all open source projects work like this. Most open source projects have a very small number of people that have commit access, for example, while Plone has relatively many contributors. This contributes to the chaos of Plone, but this inclusive culture is also one of Plone’s greatest strengths.

This also means that a summit, no matter how fancy the name, does not take any significant decisions. Instead we all do, everyone in the community, by doing what we think is the right thing to do. This means that the purpose of the summit was not to decide the future, but to give all of us as individuals a feeling for what of all our wild and crazy ideas that others are interested in. This helps us focus our efforts on those tasks that other will appreciate, and create things others have use of, and not just create things for ourselves that nobody else uses.

Again we see the power of emergent features to rise out of a sea of individualism. Plone rocks.

So, tomorrow I’m off to San Francisco for the Plone Strategic Planning Summit. It’s going to be great, the Plone community is full of fantastic people, and I had a great time at the Plone conference, and with a few exceptions all my favourite Plone people is coming. I can’t promise that we actually will come up with a straight answer to all the questions, but it sure is going to be interesting, and I’m sure I’m going to have a fantastic time.

So, what do I want Plone to be, look and work? What’s the current problems?

The first question is what Plone is? Is it a platform? A framework? A product? All of it? None of it? Well, it of course depends on how you define the words. Reinouts position makes sense with his definitions, but I’m not sure most people would use the words like that. Paul Everitt has one take on it, and I think that he uses the words slightly differently, and sees a platform as more of what Reinout calls framework. But I’m going to go with Reinouts definitions, because they seem to make sense to me.

So is Plone a platform/framework, and should it be? Well, in my opinion, it isn’t neither of them today, or at least not a good one. Plone is a good content management system (whatever Chris says ) that are easy to configure to suit your needs, and has loads of nice third party add-ons. So it’s a product, and good one at that. But is it a good platform, how easy is it to build on it? Well, after one year of Ploning, I have to say that it isn’t easy. Plone 2.5 was OK. It was a confused mess, but that confused mess centered on portal_skins, and most of the work was done in a big heap of skins that overrode each other. The trick was untangling the mess, and overriding the right thing. Once you got that, you could do most things. You usually did them in a ugly hacky way, which meant that taking over somebody else’s project usually was a minor nightmare, but that was Plone, and the Ploneish way. Ugly, but functional. A major complain of mine is that Plone complains to little when you do mistakes. Type one thing wrong in the type definition, and it just doesn’t show up, with no indication of which of a multitude of settings that are wrong.

Plone 3 tried to untangle the mess, but the effect is what a colleague of mine calls “a conspiracy on the hard disk”. Everything is done by little snippets of code spread out in several parts of the disk, which you typically have to find by doing a grep and reading loads of code. Many things, like creating a portlet, needs four files with quite a bit of repetition. There is no way to figure out how to do things, because it means you must deeply understand many parts of Plone and Zope. So what do you do? Well, you buy Martins helpful book, and copy out his code, and modify it. That works, but it’s not easy. And it stinks of cargo-cult programming. You copy out code without understanding all the bits of them, because it works. It’s not ideal at all.

We have a framework, Five, and we have a product, Plone, but I’m not sure we have a platform. Should Plone be a platform, or should we insert a platform layer in between the framework and the product?

Well, the ideal think would be if we could realize the vague plans Philipp and others have had on a Grok-style layer for Plone. That layer could easily be the platform. But creating that layer is a lot of work. Does an open source project like Plone have the stamina for something like that?