Wow, it's been a while since I've sent a message out to the greater Plone community.  I've been a bit busy over the last few months, what with having a new baby, and with internal-facing improvements to the OpenPlans software.

In the last weeks, though, I've been able to get around to some long-lingering needs which may be of interest to all of you.  Specifically, I've been getting the OpenPlans software to work on Plone 3.0, and I've put some finishing touches on the OpenPlans installation process, so that it's now much much easier for someone who wants to play around with a full OpenPlans stack to get started.  (OpenPlans, for those of you who don't know, is the largely-but-not-exclusively Plone-based software that powers the collaborative community website openplans.org, among others.)

The Plone 3 support is still experimental; it's not deployed on any of our live sites, and it hasn't yet seen any extensive testing.  It installs and works, however, and all of our unit and functional test suites pass.  And not only do they pass... they run much more quickly.  The zopectl tests are about 2.5 times faster (yes, that's 250%!) than they were before.  The flunc tests, which emulate a browser and connect to a running site over HTTP, don't see that much of an improvement, but they are consistently 20-25% faster than they are against a Plone 2.5-based stack.  Much (but far from all) of the improvement comes from Helge's refactoring of Membrane's object_implements index implementation; if you run a Remember or Membrane based site and you haven't played around with that code, I strongly recommend you do.  In any event, once we get this merged back to the trunk and installed on the openplans.org site, I'm confident there will be a very noticeable performance improvement for our users.

Equally exciting to me is that we now have some nice tools in place for people to get their own local copies of OpenPlans working.  It's taken us three iterations, but we've finally got a set of build tools and a build process dialed in that is working for us in managing both our development and production deployment environments.  And we've put some thin wrappers around this to make it easy for you to get started.  You can learn more at our getting started page.  If you're REALLY impatient you can eyeball the steps you'll have to take to get things going in the quick start section, although you'll probably also want to look at what you will need since OpenPlans does require that some other tools and services be available on your server before you can start the build.

Those of us at TOPP have had a great time building this; we hope that you find it valuable, and that you have as much fun using it, either hosted by us on openplans.org or as your own installation elsewhere.

Yeah, I know that Jon already let the Sightline Daily cat out of the bag and every day brings ever more impressive and interesting Plone sites, but before I move onto the next project, I'll afford myself a few minutes to get nostalgic.  Thanks for humoring me.  I figure anything that consumes several hundred hours+ and a few months of your life deserves at least a blog post for posterity.  Plus, I'm happy with the result.
 

So, in no particular order, here are several of the noteworthy pieces that make up Sightline Daily:

• I suppose the first thing anyone notices in a site is the graphic design and, *man*, is Sightline Daily tastefully done.   It's clean, skimmable, attractive, and presents a lot of metadata about news clippings in a non-overwhelming way.  A few times, I found myself mindlessly clicking around and just absorbing the niceness.  Sightline Institute managed the design process with Ryan Swarts and it's a great product.  My colleague David Glick implemented the CSS to perfection with some initial bootstrapping and work by ONE/Northwest friend Trey Beck.
  
• By ONE/Northwest standards, there was a rather large team collaborating on this project.  Sightline brings ~10 content editors, bloggers, content creators, and project managers to the table.  On the implementation side, we teamed with Web Collective (they focused on the blog features and portlets mostly, while I did the daily news headline-related programming), bringing the number of programmers, templaters, specification writers, and CSSers to 8.  On top of the implementation work I was responsible for, I had great time working with my fantastic co-worker, Kelley, helping to manage the biggest team I've worked with to date.
  
• I believe Jon mentioned the bookmarklet for clipping headlines, but this is fantastic.  It's the fastest method I've seen for *manually* pushing content into Plone.  Leading up to the implementation, I was a bit nervous about this piece, but equipped with a similar snippet produced for Salesforce.com by a co-worker, Steve, some inspection of the del.icio.us bookmarklet, and some Googling about, this was a cinch.  You have to see the screencast below to get a sense for how it works.  Money quotes from Sightline Daily editor Kristin Kolb were "You're saving me from carpal tunnel" and "I feel like I just received my Christmas present early" (I first demoed this in early December) upon seeing this. Awesome.  I couldn't make that up.
  

• Auto-generation of related items based on a Plone catalog query for 2 relevant news headlines and 1 blog post.  The effort to navigate to and hand pick related items was too time-consuming for the editorial process, so we wrote code that takes into account key terms to use for a query of Plone's "SearchableText" index and creates references to the returned results.
  
• A wizard-esque configlet that logically steps through the entire publishing process from choosing the date for the next "edition" of news clippings through to bulk editing all the way to previewing and publishing for site visitors.  The entire process can be done outside the context of the normal Plone user interface.  The highlight is definitely the bulk edit screen (seen to the right), which allows for starring news headlines as "top picks", editing of the keywords that should be used for auto-relating items, and drag 'n' drop reordering of stories.  Kudos to Jon for brainstorming a solid, implementable specification for this that held pretty closely from mockup to implementation.

• It's been said before, but Zope 3 brings us a fantastic event system.  The bookmarklet mentioned and screencasted above uses Javascript to get the current browser location and pre-populates the news headline with a permalink.   There's no need to slow the clipping down by forcing the editor to manually type or select the source publication as well (i.e. The New York Times or Washington Post).  Rather, site users manage a centralized list of publications (new publications are added organically over time) using ATVocabularyManager.  Using each object's permalink and Python's urlparse, we simply index the permalink's netloc for fast retrieval.  With this, we can compute and index the publication automatically.  This is where Zope 3's event system comes into play.  Because ATVocabularyManager fires off custom events upon edit and deletion of vocabulary terms, our headline's source publication stays up-to-date with some super simple event handling code.  Thanks to the kind soul that baked this capability into ATVocabularyManager, because I wasn't going to port AT-events back from Archetypes 1.5.x.
  
• Once launched and under normal load, the site turned out to be unexpectedly fast thanks to Cachefu and some minimal configuration effort.
• The site includes a nice bit of tasteful, interactive Javascript, again mostly implemented by my colleague David Glick. One can quickly expand and collapse the headlines and toggle between the days of the week. This makes the site highly skimmable.
  
• Every morning, Sightline sends out the top 10 or so headlines via email.  In the past, one manual effort involved populating the site, while another involved drafting the daily email for a blast out to subscribers.  This was a flat out waste of time and when you mix in how temperamental email clients are about HTML in email, this was a drain on Sightline staff.  ONE/Northwest often uses an ASP-based email broadcasting service called WhatCounts for the "email newsletter" part of our projects.  This service provides an incredible feature called "Smartget" (and it's near identical siblings "cacheget" and "get" -- which I like to call "Dumbget").  After the morning publishing process is finished on the site, Sightline logs into their WhatCounts instance and are greeted with a 1-line email template that goes out and grabs the raw HTML contents of the following page showing the latest news.  Prefer plain text email, yeah, we did that too.  No double entry at all.  My colleague Sam, did a fantastic job of giving me a plain-old HTML template that was cluttered with the most nasty HTML tables and inline styles needed for a consist look in the wild world that is HTML email compatibility.  I don't think in HTML 4 and tables, so this was a huge boost.
  
• Clean urls for news by topic, news by region, and rss by whatever.  I have an unreasonable hatred of nasty urls.  Try passing the following out over the phone http://www.domain.com/some/path/page?query_param=@value@&query_param_2=value2&template=some_template.htm.  That's not even social.  Thanks to Plone, we almost never have to worry about this.  Before this project, I had never noticed the "subpath" (update: I intended to write "traverse_subpath" here, not "subpath" -- sorry if that threw anyone off.) parameter that's available in Zope's request.  Essentially, you can add whatever directory structure onto the end of a skin-based template and it's right there for your consumption as a Python list in the request's subpath.  I do a bit of processing in a browser view and instead of things like ?topic=energy, we have the following clean, friendly urls:
• daily.sightline.org/news/topic/energy
• daily.sightline.org/news/region/washington
• daily.sightline.org/rss/topic/energy/region/washington
  
• In my opinion, Sightline's best content is their in-depth blog entries that are part of a series.  They've done great ones on bicycle neglect and the quest to go an entire year carfree.  Brian and Justin of the Web Collective put together a basic "series" content type and extended the blog entry, so that in the context of a blog post, the author can assign an entry to an existing series.  This isn't rocket science, but it works really well for Sightline's needs and the graphic design for a series object is one of the best templates on the site.
• Tests, tests, and more tests.  I insisted before development started that because this application was so critical to the organization, because it was fairly complex with significant code interaction, and because there was a decent sized team of folks that had no clue what other developers were doing, that we needed to embrace a test driven development approach and push as much presentation logic into easily testable Zope 3 views.  I even convinced myself that we had budgeted correctly for it ... oops.  Test driven development is paradoxically both time consuming and time saving.  At the end of it all, I don't regret the decision to adopt this approach one bit.  I doubt few do.  At the time of this writing we have 399 unit tests and all of them pass but 1, which I left unfinished to remind me of a feature I couldn't get working within the bulk admin interface and therefore disabled entirely. I wanted to finish that, but it was unnecessary and I needed to move onto other scoped items.  The fact that we still have entirely passing tests after site launch for the enabled features signifies that even as we approached the looming deadline, we didn't abandon our agreed upon approach.
  

So, there you have it.  I suppose I could write another post or two covering all the lessons learned and the endless details that went into getting this site launched, but for now, I'll leave things at that.  It's best to reflect on what worked well in the end anyways.  Furthermore, I think Jon still plans to do a case study and possibly a screencast about the editorial process.  That will certainly be interesting and take a closer look at the big picture.

I've been using zc.buildout for a few months now, and am quite happy with it.  However, I got tired of navigating to my egg cache, locating the right package (and version) within a long flat list, and then clicking a few more times to actually get to the contents of the package.  And I was looking for a project to practice my buildout recipe fu.

So I created collective.recipe.omelette.  It's a simple buildout recipe that takes all your namespace-packaged eggs and merges their contents together into a single directory tree, in its own parts directory, with symlinks to the actual egg contents.  The result looks much the lib/python of days gone by.  So instead of:

egg-cache/
    my.egg.one-1.0-py2.4.egg/
        my/
            egg/
                one/
                    (contents of first egg)
    my.egg.two-1.0-py2.4.egg/
        my/
            egg/
                two/
                    (contents of second egg)

you can now make use of:

parts/
    omelette/
        my/
            egg/
                one/
                    (contents of first egg)
                two/
                    (contents of second egg)

with obvious advantages in navigability and greppability.

Collective.recipe.omelette is available from the Cheese Shop.  You can add an omelette to your buildout by making the following additions to buildout.cfg (assuming you have a part called instance and you want to generate symlinks for its eggs), and then re-running your buildout:

[buildout]
...
parts =
    ...
    omelette

[omelette]
recipe = collective.recipe.omelette
eggs = ${instance:eggs}

One caveat: Since this makes use of symlinks, it of course won't work on a filesystem that doesn't support symlinks, such as Windows'.

I haven’t posted much here lately, but I have been writing. I recently finished my first semester as a doctoral student in Columbia's school of journalism and one of the papers I completed draws directly on my experiences in the Plone Community.  A few years ago I remember being struck at how different open source development was from what I (and presumably others) imagined it to be. I kept pitching human interest stories to journalists, ones that might emphasize the playfulness, the sprinting, and the organizational experimentation, but got very few nibbles. So, I finally wrote some of this up myself before it all fades from memory:

The paper was for a wonderful class this semester at the New School taught by Paolo Carpignano (The Political Economy of Media - here is the syllabus). The class was all about the shifting relations between fabrication and communication, or more colloquially, work and play. We opened with Marx and Hannah Arendt and closed with Yochai Benkler and danah boyd. The piece I wrote is personal and anecdotal, but reflects on all that our community has taught me about free software, free culture, organizing, consensus building and the day to day politics of software development.

enjoy.

On the off chance that you're like me and prone to falling behind on your various Plone list-related reading, I'm soliciting feedback on my plan for ticket #7813 aiming to "make sure the "strategic integration" story with other systems is visible and documented".   Comments welcome.  Full plan below:

With ongoing support, feedback, and guidance from the broader Plone
community, I volunteer to serve as "champion" of trac issue #7813,
'Make sure the "strategic integration" story with other systems is
visible and documented' (http://dev.plone.org/plone/ticket/7813).  I
will do so by offering to invest time/energy within the following two
focus areas:

1) Developing code, making increasingly better releases, documenting,
and marketing for the Plone integration with Salesforce.com as the/a
Plone Customer Relationship Management (CRM) story

2) Beg, bribe, borrow, and steal case studies and documentation of
successful implementations of Plone integrating with system X for
plone.net and plone.org/documentation. I'm not able to offer code in
this department, but I will aim to highlight successes and possibly
over time aggregate pain and resources for new integration territories
we'd collectively like to explore.

=-=-=-=-=-=-
Deliverables - I.E. what will exist in 6-9 months
=-=-=-=-=-=-

Plone with Salesforce.com serving as CRM:
 - Increasingly more mature releases of the following suite of
products: http://snipurl.com/plonesfproducts
 - A solid manual at:
http://plone.org/documentation/manual/integrating-plone-with-salesforce.com
 - Personal and Plone community participation in:
http://groups.google.com/group/plonesf/topics
 - Increased use of the term "CRM" in close proximity to the word
Plone, so that folks Googling for a CRM that works with Plone see this
as a strength for Plone, rather than a weakness.

Shed light on the "strategic integration" story:
 - 3-5 "integration-centric" case studies exist on plone.net
 - A "3rd party integration" category for: http://plone.org/products.
Ensure tagging is happening.
 - Enhance "Plays well with others" section of Plone.org homepage
under the "Standards Compliant" section
 - Bonus points: Hightlight commonly needed integration stories
hopefully causing new tools/documentation to emerge

=-=-=-=-=-=-
What success looks like
=-=-=-=-=-=-
I don't think the above alone will accomplish this, but it's a start.
I think longterm success would be:

- Members of other software communities (i.e. Salesforce.com, Moodle,
Facebook, <insert system that can be integrated with here>) learn
about and deem Plone a viable and *complimentary* CMS.  This knowledge
is learned within the context of their existing communities.
- Integrates well with X is easily found and helps certain decision
makers decide to use Plone.  Seminal "why we chose Plone" blog posts
appear citing integration as a key reason :)
- Plone continues to thrive by staying focused on what it does best
(as seen with future code Plone releases).  When strategic, Plone
integrates nicely in order to avoid spreading itself too thin.

=-=-=-=-=-=-
Call for Participation
=-=-=-=-=-=-
If Plone's integration makes you excited.  Logical next steps include:

1) Give me feedback on this plan
2) Watch ticket #7813 at http://dev.plone.org/plone/ticket/7813
3) Tell me on list of off list what you've integrated Plone with and
why you think it's interesting.  We'll turn interesting stories into
case studies.
4) If Salesforce.com as a CRM for Plone excites you, join this Google
Group: http://groups.google.com/group/plonesf/

Hopefully this is pretty clear and actionable.  I look forward to the
ensuing discussions.  Let me know what I'm missing and what seems
vague or unachievable.

... or "So, we're hiring a database developer to help with CRM implementations ..."  But, that alternate title isn't really the point (unless you're interested ;) )

As far as I know, the following PloneFormGen "Form Folder" is the first publicly available, advertised, and production use of the Salesforce Adapter for PloneFormGen (please correct me, if I'm wrong).  If you haven't heard about this piece of code that connects Plone to Salesforce.com via PloneFormGen, you might want to start here or here. 

This is great for a couple reasons:

• The particular use case (i.e. collecting applicants for an open job offering) is one that I certainly never would have thought of -- and that's the point.   Creating these shouldn't take a Plone developer.  Nor should coming up with the possible use cases.  It should be the responsibility of staff that need to build the relationships they need in order to do their work.  My colleague Steve is no slouch with CRM and Salesforce.com, but the portion of getting this on our Plone-powered site doesn't take any additional expertise.
• It will help flush out any bugs, so that we can push onto a more mature-sounding release (i.e. final, not beta or release candidate)
• It comes equipped with the following explanation, which I think is fantastic:

Geek FYI: this is a form built in Plone that sends your data directly to our Salesforce.com database. We'll receive a notification when that data gets created. You'll also be automatically added to a Campaign that will capture all applicants. I've got a view in the Console for keeping track of all the applicants for this position. If you understood all that, or really want to, that's a good sign...

So, um, test it out if you want...

Finally the software has been released. Last year there was a Ploneability High Education event held in November at the University of Houston. I promised a few things during that presentation. We have followed through and I want to explain to the wider community our motivations.

At the Ploneability event I said Desktop 4 would be free. Desktop is now available to download. I also want to highlight some features: decoupled Desktop from Plone, the UI is now mostly asynchronous, fixed tons of bugs. We now feel that Desktop 4 should be widely distributed and urge everyone to use it.

Specific highlights:

• Enfold Desktop no longer requires Plone. The Desktop Server components for CMF/Plone add "more functionality" to the user's experience. Such as workflow control and property sheets. But the server components are no longer required. In this mode Desktop users simply have fewer options. They have a very nice and reliable DAV client that is more predictable than Microsoft Web Folders. You can now use Enfold Desktop with Plone, Zope, CMF, mod_dav, IIS, etc. In fact we urge you to use it on any DAV server!
• Performance. The UI was originally synchronous. This meant you could do one thing at a time. If an operation took a long time (say uploading a 100MB file) your Enfold Desktop would become unresponsive. This is no longer the case. You can upload and download multiple files at once and edit files -- all simultaneously! The user experience is significantly better because of these performance enhancements. Give it a shot and tell us.
• Bug squishing. Not much else I can say. We added a Report a bug feature. Also if desktop does something unexpected it will prompt the user to send us a message (it also sends internal logging). This has helped tremendously. We have uncovered loads of bugs and fixed them. Often bugs that end users were unaware of but were still happening under the covers.

Why we released:

Enfold Systems is very interested in acting as a good community citizen. We believe that Enfold Desktop will enable people to win more consulting projects. If they want support and to remove the ads - they can pay us. But the result is the consulting community is often asked for Windows Desktop integration and there was no de-facto standard. Enfold Desktop aims to be that standard. By having the broadest adoption of Enfold Desktop there will be a coherent Plone / Windows Desktop integration story.

This is only the beginning. We have laid one piece of the foundation. Plone has a complete DAV integration (server and client). But it needs much more. Specifically we need software developers to make their software DAV compliant. This requires the entire community to buy-in. There are many reasons for DAV compliance. One example could be import/export.

An example is having a representation of content outside of the CMS, say in the case of exporting. Also a way to create content by importing this representation. So the import/export story, I believe, could be tied to having a DAV representation for content. Plone still does not have a full import/export story that is 100% textual and independent of the storage medium. Customers want repeatable import/export.

Another could be creating a cross platform editor for content. We now have Enfold Desktop and External Editor. But we can not edit "rich content types". This could be very interesting. Double click on content and have it open up in a rich editor that supported calendar controls. We have a higher level of abstraction other than "File". It would be a pity for everything to be file oriented.

If you do not keep up with IT analysts writings. Plone is the big kid on the block when it comes to Open Source content management. Desktop integration is one facet to CMS. The plone community now has a great foundation to make a much richer experience. And an immediately useful Folder/File-level DAV integration for the Windows Desktop. But it will require more from the community. Specifically users asking product writers to support DAV. Because it is the product aftermarket that makes the Plone CMS so powerful. Commercial CMS's do not have such a flourishing aftermarket. The Plone aftermarket is continually building and sharing 24 hours 7 days per week.

Lastly I would like to clarify Enfold System's position when it comes to open source and Plone. Enfold Systems is the Windows open source content management system specialist. We focus on providing product, services, and integration to organizations that want the power of the open source Plone content management system while reusing their existing Windows infrastructure. This is very important for large organizations. This is our niche. Our customer's want a vibrant community. So as we provide service to a wide variety of organizations from small-medium size non-profits to fortune 100 companies - Enfold Systems is trying to build a sustainable open source model. A part of this manifests in big releases like Enfold Desktop 4 being released. But more often than not you can see aftermarket Plone components such as the magnificent UploadReferenceWidget and the visionary Entransit Content Deployment all the way to unseen bug fixes to Python COM bindings, Zope, and Plone. PLIP 187 is an example of us feeding changes from product development back into Plone proper. Enfold Systems sees releasing Desktop as a way to grow the Plone ecosystem. Also to maintain visibility that Enfold Systems is both the premier Open Source Windows CMS provider and the Plone experts.

Plone Release Manager Wichert Akkerman sent the following email to the plone-developers list today, outlining the schedule for Plone 3.1, which will end with a final release in March 2008.  Plone 3.1 will be a small release with a few new features and no major architectural changes.  It will be a seamless and safe migration from Plone 3.0.

In coordination with the new framework team I am happy to be able to announce the timeline for the next Plone feature-release: Plone 3.1. The release process for 3.1 has very specific goals:

Safe changes only: since this is a minor release which should not destabilize Plone 3.x only changes that are risk-free will be considered. This means that no or very minimal migration steps are allowed, everything has to be properly tested, documentation has to be in order and the user interface has to be finalized. This also means that 3.1 will be based on the 3.0 codebase: Plone trunk has far too many major changes already.

Do not overload the framework team: the deadlines are fast and strict, so making it easy for them to rest proposals is important. The best way to do that is to create a buildout based on the latest Plone 3.0.x release and include only the changes relevant for that proposal.

Quick release schedule: we do not want to take 9 months to get this release it. This means that all proposals have to be completely done and polished in order to be acceptable. The migrations, if any, have to be in place and working, there have to be working tests and the user interface must be complete.

This is the timeline for 3.1:

  2007-12-14 : PLIPs for all features have to be finished and submitted

  2007-12-21 : framework team gives verdict on PLIPs only, not an implementation

  2008-01-19 : review bundles have to be submitted to the framework team

  2008-02-02 : framework team completes reviews

  2008-02-08 : 3.1 pre-release tagged

  2008-02-11 : 3.1 pre-release with installers released

  2008-02-15 : 3.1 release candidate tagged

  2008-02-18 : 3.1 release candidate with installers released

  2008-02-29 : 3.1 final tagged

  2008-03-02 : 3.1 final with installers released

Note that there is a change from the procedure we used for Plone 3.0: there is now an extra PLIP-review step. This has been added to allow us to check of a proposal is not too invasive or for some other reason undesirable for 3.1. That makes sure that nobody will be trying very hard to make a deadline only to hear that their work is not going to be considered.

As you can see this is an ambitious schedule. This means that we have to be very strict in what will be accepted and what won't. There is no shame in missing a deadline - we are all busy people and sometimes a deadline is just not attainable. Anything that does not make it in can be reconsidered for 3.2 or 4.0.

On a whim (it was planned 2 days ago), some of the Seattle Crew decided to get together this weekend and sprint.  The goal is ambitious, but simple: to fix a bunch of bugs and add futures to increment the releases of our Plone/Salesforce.com integration products.  I'm hosting in good ol' Ballard, Washington.

Pictures of jonstahl, healingKnee, jessesnyder, brianfive, and davisagli below:

This is a fun post recognizing the role of open source software and breaking routines in learning new programming patterns and paradigms.

7 Reasons I switched back to PHP after 2 years on Rails

Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines. I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby. But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!

This story articulated an idea that I have been thinking about for a while - the ways in which developers working on open source software enter into an educational relationship with the software and the community (sometimes indirectly, mediated through the code).

I have often appreciated all that Plone has taught me about the domain of content management, component architectures, extensible software design, internationalization, test driven development, responsible release management, etc etc. I know that it has taught me well since when I walk up to new pieces of complex software like Sakai or Drupal the concepts are familiar and often isomorphic. I can vouch that exposure to Plone has helped designers I know with stretch their CSS skills, improve the accessibility of their sites, and more cleanly separate presentation from logic.

I have also made the case that for an organization to work on software in isolation is bit like having a conversation with yourself. At first you might arrive at some new insights, but its really hard to learn anything new in a hermetically-sealed vacuum chamber. The software world transforms so quickly that it is a Sisyphean task for any one person or organization to track. Joining a community, even if it is through the indirect, intermediary object of code, is a great way to continue learning and stay on top of emerging trends. The notion that learning happens through dialog is an old one; the notion that working with open source software is a form a dialog with the authors is a bit less obvious.

My main critique of Derek's post is that he doesn't explicitly acknowledge the fact that Rails is open source, which is precisely what enabled him to learn so much from the framework. This isn't just a matter of attribution, it has practical implications for being able to continue learning new tricks over time.  If he had realized that Rails-the-software embodied the knowledge of the Rails-the-community, he might not have been so quick to venture off and write his very own framework. I am not arguing that he should have steered clear of php, but he does not explain why he decided to roll his own framework as opposed to joining forces with Cake or another existing php framework, or at least using an existing php templating system. With a more explicit understanding of the origins of the knowledge that Rails-the-software captures, he may have appreciated the potential future gains of remaining part of some community.

While it is possible to learn something from proprietary frameworks, "learning" is fundamentally about the open exchange of knowledge and meaning, which are values intrinsic to F/OSS. While you can learn something from a .NET api, you can't step through the entire stack of software in the debugger. Perhaps more importantly, the cultural tendencies on an open project support constructionist poking and prodding (dare I say, hacking?).

Many of us are familiar with the One Laptop Per Child project, which is making technology and information more accessible. Eben Moglen talked about this at his keynote at the 2006 Plone Conference (link to video, youtube version). What struck me as most powerful about the project was the clear, concise design principles. From the principles, you know exactly what the project is, and without any of those things, it would not still be OLPC.

At the Moglen talk, I asked about what Plone's design principles are. The question was more for the community, and a lot of people seem interested in the question (and it's answer!) over the last year...yet nothing happened. So, a year later, I started an informal survey at the Naples conference.

With the idea of making a draft of what Plone's core design principles are, I have been asking people around the conference, including core developers, board members, integrators, end users, new developers,...though there is obviously a diversity that we would expect from our community, I am trying to synthesize here the responses, with the intent of submitting the words of the community back to the community for review :)

And with no further ado...my attempt at articulating Plone core values:

1. Easy to use (to add/edit content)!
Responses: Easy to use (highest hits of any), usability (high number of hits), intuitive

This is the bread and butter of Plone, the part that every one of us experiences when we see it and use it, and the fundamental part of . Plone's commitment to usability since the beginning is apparent in the product and the community, and it is core to Plone to make it easy to use for content management.

2. Approachable
Responses: sensible defaults, easy to get, easy to deploy, easy to download and install, opportunity/potential, giving technical people (though not necessarily developers) a great system that they can gradually get more into the customizing with a steady and approachable learning curve.

This principle is about making it easy for people to get into Plone and get hooked on how cool it is, and then be brought through a manageable learning curve as they do more of their own custom implementations. It means out of the box, the settings make sense and that we empower people with tools that give them lots of potential. It also means that smart scripters (even without Plone development experience) can get into doing custom work also.

3. "Developer Nectar", ie Built to Last, quality framework
Responses: Safe customizations, smart adaptability, easy to extend, extensible, easy to develop, user centric, use case driven, best practices, web standards, accessibility, good error messages, cross platform, test-driven, solid development, open source, scalable (up and down), passion for the technology (doing things the right way, even if it is a new technology).

Moving on from those getting into the customizations, there is the more serious development work in Plone, which is solidly built on best practices (web standards, accessibility, development process, test-driven, etc). This is about helping developers learn about and adhere to good practices, as they get deeper in the system, by having defined processes and practices. It is also about using cool technologies that keep developers interested and having fun. Finally, it means that we provide direction to the developers that originates in the way people want to use the system, captured as use cases.

4. Fun! Community!
Responses: fun, fun atmosphere, entertaining, community (one of the more popular responses, though without certainty that it applies to Plone the software, but knowing it is essential to survival and sustainability of Plone)

Some intertwined concepts here, that I am calling Fun & Community. First on the fun: this is about being fun to use and develop with, as well as being a thriving community with amazing people. The community is an obvious part of anyone who already participates. It is amazing, whether it is the "mindshare" or finding others working in your area, or just having a great time with passionate, bright people, Plone's community is a huge asset. Without it Plone wouldn't be Plone. The community also provides lots of support, which helps sustain it and make it more approachable.

So, that's the core. Definitely needs language refinement and maybe also refactoring, but I submit it for your review :)

There is one item I am on the fence about. It is something that is not core now, though important, and which, if it were to be core, would affect certain decisions and involve some tradeoffs. That item, is "collaboration" as a use case for Plone the software (there is tons in the community itself, which is not what I am referring to here). There are definitely some collaborative features in Plone, but most are through addons or configurations (a few new ones in 3.0, but still lacks several).

Conclusions

The idea of core values or design principles is that they are the things that never change, that, if removed, would take away the Ploneness. The core principles don't necessarily have to unequivically describe the current product. The fact that we don't already have these principles articulated means that it may not be true, but it should help us to enhance the product in the future.

This is being submitted for comment and review from the community. The idea is *not* (did you miss that? I said NOT) to make a long list. Core principles lists should be as small as possible; the goal is not a comprehensive list of things we like, but instead the smallest list of things we can't live without.

One note about timeliness...as announced at the conference in the State of Plone talk, there will be a Plone visioning/strategy meeting in Feb 2007 at the GooglePlex. I strongly believe that we need to identify the core principles[1] before we engage in visioning, so here's my small contribution to that.

From talking with others in this process, I got a lot of good, complementary ideas as well as clarification on this excercise. I want to thank Paul, Jon, Martin for supporting the inquiry process. 

References:

[1] The book, Built to Last, is a classic presentation of the concept of core values as necessary for a company/organization/movement's longterm success. It defines these as the small collection of values that *never change*. These are the heart, stability of the institution.

The Product Developers email list, which was started in early 2007 as an outgrowth of Martin Aspeli's session at Plone Conference 2006, has really blossomed into a vibrant, active community of folks working collaboratively on add-on products for Plone.

It's a tremendous resource if you're developing an add-on product, looking for advice about an existing add-on product, or looking to make suggestions for how you'd like to see an add-on product evolve.   I plan to follow this list a LOT more closely from here on out, and I encourage you to as well.

You can subscribe via email or read it on the web via Nabble.

The amazing and indefatigable Darci Hanning is helping organize a "social source" sponsorship effort to raise $2000 to support Lupa Zurven's work to update CalendarX for Plone 3.0.  CalendarX is a widely-used calendaring add-on Product for Plone -- if you'd like to see it updated for Plone 3.0, now's the time to join together with other Plone community members and make it happen.

Lupa's sponsorship goal is $2000.  As of this morning, there are $700 in pledges.  They're using Fundable.org (a Plone-powered site!), which lets you make a pledge in any amount from $10 on up, and you'll only pay if the $2000 goal is reached.   With $1300 to go, we only need another 26 people to pledge $50 each. That's peanuts, especially compared with the number of folks who've benefitted from CalendarX over the years.

This is the funding model we used last year to sponsor a round of work on Ploneboard, and has also helped drive the GetPaid project forward. It's a great way to share the load of sponsoring useful products for which there isn't a single big customer. 

I hope you'll join me in sponsoring CalendarX.

Update - Tuesday, 5:30pm PDT: We're now at $950, nearly halfway there!

If you are currently a member of the Plone Foundation, and wish to remain so, you need to renew your membership for 2008.   Consider this a gentle reminder.

Plone Foundation membership committee chair Godefroid Chappelle explains: