Postal heritage and Plone, or: how I learned to stop worrying and love Content Management Systems is one of the most powerful and well-written nonprofit technology case studies I've ever read.   The fact that it's about Plone is almost an afterthought.  Almost. ;-)

It starts with the client's story -- a unfortunately-too-typical nonprofit story.  Steve Gardam, web manager for The British Postal Museum & Archive, explains:

The website content was reviewed in June 2004, and we found many small content errors. This became a bigger problem, as it emerged that the previous ‘friendly’ arrangement to update content was no longer possible, as Royal Mail Group [their former parent organization] had outsourced its ICT. The high cost of editing content meant that the site was to stagnate for several months. Perhaps it was a blessing that were we also unable to obtain website visitor statistics during this time!

After a RFP process (that's ITT -- or Invitation To Tender -- in Her Majesty's English), they chose Adaptive Technologies Limited (ATL).

We found ATL’s responses to our queries measured and open. We also felt that they had the greatest understanding of the heritage sector, perhaps because they are themselves owned by a charitable trust and are based in a Regency heritage centre, in Brighton.

We liked the fact that ATL’s solution suggested using open-source software (Plone) for the CMS, as we were wary of getting tied in to a company-specific system. There were no real differences in price between the companies, because they all tailored their solutions to the ballpark budget we stated. Our choice was based on the overall approach of each company to working with us, and I’m pleased to say we have made a good decision.

Two things jump out at me here:

1) Nonprofits like to work with nonprofit consultancies -- because there's a cultural fit that leads to greater trust, and greater understanding of nonprofit problems.

2) Open-source solutions lead to consultants that have an open, collaborative attitude, and that's what wins contracts -- assuming open-source can make the price.  Which in my experience, it usually can.

Skipping over the (very good) bits about project management and timeline management, we come to their experience with Plone-the-tool:

Learning to use the CMS was initially a very frustrating experience, but no different than learning any new ICT application. For example, when using the WYSIWYG editor, copying in text from Word documents can sometimes lead to muddled formatting, but this is something that is learned, anticipated, and then becomes less of a difficulty.

The system becomes increasingly intuitive with practice, and the user interface is logical, with options to view, edit and publish pages. We have built a publishing workflow into the CMS, enabling authors to create content and publishers to review and publish. Thus far, we have not rolled out the CMS to a wide number of staff, but our site, like our organisation is relatively small.

Things to be wary of...

The logic of the interface has occasionally proven to be a false friend. For example, the content is arranged in folders containing documents and flies, much like Windows Explorer (WE). However, the behaviour of the CMS folder structure is not a perfect analogy for WE, which I nearly learnt the hard way when I cut out some data and was unable to paste it back – happily ATL was able to rescue the missing content. ATL have promised several improvements to the system that we hope to include in an upgrade later in 2005.

The CMS ran very slowly to begin with, but ATL acknowledged this and worked on it to improve the speed. Having spoken with colleagues who use different CMSes, our Plone CMS now runs at a rate they would consider typical, if not better.

The story could have ended right there.  But then Steve passes the mic to the consultant, Danny Hope, lead designer and project manager for Adaptive Technologies Limited.

It appears that this was ATL's first Plone site.  Danny explains the rationale for choosing Plone instead of rolling his own solution:

For some time I had been researching the requirements for a new CMS that I would design, and that the ATL in-house team would build. My new CMS would be a universally accessible and usable vision of beauty, capable of letting anybody edit any website quickly and easily, it would be perfect… I felt this was within ATL's very strong capabilities, until I discovered Plone. I was so impressed by what Plone could offer that I abandoned the idea of a new CMS, and decided to join the open source movement.

Smart move. ;-)

Danny then describes the modifications they made to Plone, and more importantly, the process of listening to the client to identify their needs:

Although Plone is a very powerful and up-to-date system, our experience of working with end-users indicated that Plone's 'out-of-the-box' editing interface could be improved, particularly in terms of usability. With this in mind, our development team tested and implemented a number of significant changes. These now provide an easy-to-use CMS for the BPMA and a better version of Plone for us to offer other clients in the future.

As well as these general enhancements, we also wanted to ensure that the CMS was suited to the BPMA's actual working practices (CMSes tend to fail when they force organisations to make unpopular changes to their working practices). To do this we conducted on-site interviews with BPMA staff to gain an understanding of how they would use the system; studying their working practices, understanding their expectations for the CMS, and analysing how its introduction was likely to affect the organisation.

This study led us to remove unnecessary or overly complicated features and add a number of custom tools to the system. We also used our analysis to configure Plone's built-in workflow mechanism to suit the BPMA's working practices, reducing resistance to the introduction of the CMS by making it friendlier to use.

I would love to hear (and see) more about these "usability enhancements", especially on the back end.  The public site looks very clean and streamlined. 

OK, I've probably rambled on long enough.  But with a Plone Symposium tutorial about "Nonprofits and Plone" to prepare for, I need all the great stuff like this I can get.

No, seriously, not only is this a great testimonial for Plone that takes into account Plone's strengths and weaknesses, it's also a great lesson in effective technology management practices for nonprofit organizations.

Way to go British Postal Museum & Archive and Adaptive Technologies Limited!

PS Their colophon is a thing of beauty.  It's even got Flash movies that demonstrate Plone.  Wow.

I just wanted to share some love for CompositePack, which is Godefroid Chapelle's awesome product for creating composite pages in Plone.  We are using it to build the homepage of our about-to-launch new website, and it really works beautifully.  It really shows off how powerful Plone can be while retaining great usability.

One suggestion I'd offer is that it would be really nice to have a default viewlet for Smart Folders that would list the items found by the Smart Folder in a compact bulleted list.

This would make it easy for non-technical users to create a slot that lists items found elsewhere in the site.  Bonus points for lettting the user configure the number of items listed in the slot.  (I can easily image large Smart Folders where one might only want to show the first few items in a slot.)

Thanks, Godefroid!

(Love is also due to Shane Hathaway, who created CompositePage, upon which CompositePack is based.)

There's been some interesting conversation about the future of taxonomies in Plone over on the Plone Developers list lately.  In particular, Arnar Lundesgaard's responses to Martin Aspeli's smart questions are worth reading closely.

Martin's questions, as summaries by Arnar, were:

1. You'd like better categorization in Plone, not just folders and smart folders and were looking for opinions. You also mentioned some approaches in your mail to the list.

2. You wanted to know sort of categorization systems that "works in the real world", mentioning RDF triplets and tag clouds as examples of systems you have heard of.

3. Something that can be quickly implemented in Plone but that you do not have to rework for the next version of Plone.

Arnar's response is too long to reproduce in detail, but a couple of the less-technical bits that leapt out at me.

First, on the importance of user stories and usability:

First, you need to figure out what and how you would like to present the
functionality to the end-user before you select any technology.

Interaction design is the key phrase. Keep it simple. We learned early on that all the flexibility in the world does not matter if our users are unable to understand or use the features.

On the pros and cons of tags:

Advantages:

1. Tags capture your own context at the time of tagging.

2. Tagging makes you stop and think about what you are classifying.

3. Tags use your own words and perspectives of what is important.

None of these work as well when you are classifying for others:

1. Visitors do not share your context, experiences or view of the world.

(This is a problem for other categorization systems as well, but [particularly true given] the freeform nature of tagging.)

2. Folksonomies (ala del.icio.us) work because you can to a certain extent rely on crowd-wisdom. This may not be possible in other systems.

3. Tags tend to be generic, meaning lots of hits for each tag.
(This suggests that it is the intersection of tags which is interesting and a decent interfaces might overcome this. See Jon Udell.)

4. Synonyms, or multiple tags meaning the same. (Or do they?)

5. Tags may be problematic [on] multilingual websites.

6. Free-form, how do you manage the tags?

All of the problems with tagging or similar keyword based systems may be worked around, though I believe you simply end up creating an ontology language. (Often a poor replacement, though that does not mean it is without value).

While cool, tag clouds are just a visualization and perhaps not the best way of navigating a document collection. (Nor area they a well known pattern from a usability perspective)

Finally, even poor tags are better than nothing.

On making classification easy for end-users:

Classification carries a cognitive cost, meaning that it is work, even hard
work. You want your system to minimize the cost of doing this (what tagging
does so well). AJAX techniques *really* help here.

On the importance of understanding prior art before implementation:

I recommend studying literature on patterns and usage of existing technologies like RDF and Topic Maps before implementing your own classification system. I certainly found that very illuminating and it helped to clarify my own thinking.

Very smart people have thought about these problems for decades and repeating their experiments and mistakes might [be] time consuming.

Lars Marius Garshol's "Metadata? Thesauri? Taxonomies? Topic Maps!" at
http://www.ontopia.net/topicmaps/materials/tm-vs-thesauri.html is a good read.

Good stuff.

One of the signs of a mature open-source community is that community's ability to grow new leaders and to evolve leadership processes that are appropriate to the community's increasing size and ambition.

So, it's really cool to see that Plone's first "Framework Team" (Alan Runyan, Alec Mitchell, Michel Pelletier, Benjamin Saller and Whit Morris), which took responsibility for the upcoming Plone 2.5 release, has handed over the reins to a new, larger group for the Plone 3.0 cycle.

These are the folks who are officially responsible for making the final decisions about what code to recommend for inclusion in Plone 3.0, and for driving the overall process of reviewing PLIPs (Plone Improvement Proposals) and bundles of submitted code. 

Your love, appreciation and code bundles with unit tests they all deserve.

Here's Whit's announcement to the plone-devels list.

I'm proud to present to you the new voting members of the framework team. Based on interest, we have a well rounded seven!

========
FWT II
========

Wichert Akkerman
Martin Aspeli
Rocky Burt
Raphael Ritz
Hanno Schlichting
Vincenzo Di Somma
Helge Tesdal

This voting body is effective now. In their first vote, they elected Martin Aspeli to act as the official spokesperson for the group. You, plone-at-large, may start submitting PLIPs w/ code bundles for their review for inclusion in Plone 3, the (enter tagline here).

-----
FAQ
-----

To clarify any confusion, I've included some answers to some frequently asked questions.

Q: What does the framework team do?

A: The framework team is responsible for recommending code for inclusion in a Plone release to that release's manager. In the release cycle, they drive the PLIP and bundle code review cycle.

The voting members do the formal duty of collecting information from the community about bundles offered for review, and making the formal decision by voting whether to recommend them to the release manager. One
member of the group is chosen from within the group as the framework team lead and is responsible for communicating all decision of the team onto the plone-devel list.

Q: Who is on the team?

A: Anyone who wants to review code and is interested in actively participating with shaping the technical vision of Plone's future. Each release, a small group in a similiar timezone is chosen to cast the actual votes on proposals (PLIP + bundle) on the advise of the larger team.

Q: How/when are the voting members chosen?

Currently, voting members are chosen arbitrarily on a rigorous *wink* criterion of general interest, recent contribution, timezone and who the former voting members thought would do a good job. As the framework team is dedicated to evolving process, this is open to become a more formalized democratic process.

New voting members are active after the first alpha of a new release and remain active until the first alpha of the next major release.

Q: What happened to the old framework team?

A: The former voting members are still part of the team and will help out with code review. Whit Morriss (aka me) has offered to stay on as a non-voting member (oxymoron, yes) to help with continuity and as a community liaison (read, svn-nanny).

Q: Sounds groovy! How can I participate? (I just can't get enough e-mail from Martin...)

A: Thought you would never ask... the new voting member probably have some ideas, but here are some broad strokes that go from early in the release cycle to late:

* Participate in / start technical discussions of possible PLIPs on plone-devel (preferably with prototype code). This also includes discussions of use-cases and end-user needs.

* Join framework-team@lists.plone.org and participate in discussions of
refining development process and codification of developer best practices.

* As plips come in, help plippers make bundles and prepare their code for review.

* As bundles get ready for review, review code and report your findings to the voting members.

* take off your framework-team hat and help get that release out!

If after this the experience moves you, and you want to bear the responsibility of voting and encouraging others to review code, let the current lead know of your interest.

cheers!

-w

A couple of random thoughts about this:

• I noticed that the new members are listed on the Plone.org Framework Team page, but that much of this helpful FAQ is not yet on there.  (Hint, hint, hint.)
• Chosing Martin Aspeli as the "official spokesperson" was really smart; in recent months, I've been extremely impressed by the clarity, smarts and grace of his communications with the Plone world.
  
• Recruiting a new team for each release is smart -- this helps avoid burnout and makes sure that there is fresh perspective brought to each cycle. 
  
• I have to think that Plone's model of decentralized leadership within a well-defined, transparent framework is a huge long-term win for the platform as it navigates a complex landscape of peers, competitors and collaborators.
  

This week, Alexander Limi busted out updated roadmaps for:

1. Plone 2.1.3 -- the upcoming "maintenance release."
2. Plone 2.5 -- the next "infrastructure release."  Actually the infrastructure stuff is well along, Limi's post focuses on ancillary UI and configuration improvements.
   
3. Plone 3.0 -- the next "big features release."  
   
   

These posts, and the ensuing conversations about them, are must-reads if you're interested in understanding the future of Plone.

I don't know about you, but this stuff makes me drool.

Update 2/19: The Plone 3.0 thread has evolved into a quite-fascinating discussion of AJAX frameworks, and which approaches Plone ought to adopt for AJAX-ifying its user interface. A great crash course in the relative merits of prototype.js, MochiKit, AZAX, and others. 

For anyone who's been developing w/ Plone for a while, it's hardly news that the QuickInstaller and the Plone migration engine leave a bit to be desired.  This article discusses a way that GenericSetup might be used to provide the functionality of both of these systems in a more elegant fashion.

First it is important to understand some fundamental GenericSetup concepts.  GenericSetup introduces the idea of "setup profiles", which are a collection of XML files that describe aspects of site configuration.  To get an idea what a setup profile looks like, you can browse through Plone's default profile from the subversion trunk.  One thing to notice immediately about setup profiles is that they're declarative, not procedural; they describe the state that the site should end up in, not the steps taken to get there.  Contrast this with the existing situation where site configuration can only be specified by a set of procedural python statements that actually perform the configuration.  With GenericSetup, the procedural code is encapsulated into import / export handlers that know how to interpret the XML files of the profile and generate a configured site, and vice versa.

The setup profile that defines an initial site configuration is known as a "base profile".  In addition to base profiles, GenericSetup supports "extension profiles", which (as you might guess) extend the base configuration with additional configuration options.  Extension profiles usually specify such things as additional skin paths, additional content types, additional actions, etc.  In short, pretty much all of the things that are usually handled by the Install.py module that QuickInstaller expects to find.

This then hints at the first part of the puzzle.  Rather than creating an install method to be called by QuickInstaller, add-on products would define an extension profile that could be applied to the site.  Installing the product would merely mean applying the extension profile to the site.  Installing is the easy part, however; uninstall and reinstall support is quite a bit trickier to get right.  Luckily, GenericSetup provides some mechanisms that can help with this.  First, there are snapshots.  A snapshot is simply a site export that is generated at a specific point in time and saved in the ZODB.  Snapshots can also be compared to one another, providing an overview of what site configuration has changed in the time between when two snapshots were taken.  If a snapshot is taken before an extension profile is applied, and then again afterward, it may be possible to determine what configuration changes actually occurred.  Also, later snapshots can show what changes were made from when the profile was applied and some later time.  Getting a perfectly clean automated uninstall will be tricky, but at the very least it should be possible to get a good idea about what needs to happen, and to even get warnings about later customizations that would potentially be impacted by the removal of the extension profile.

Another idea that GenericSetup includes is that of versioning the specific import steps in a profile.  This is not yet implemented, but the idea is that you will be able to look at an existing setup profile to compare the version of each import step with the version at the time the profile was originally applied to your site.  Any import steps that were out of date would be able to be reapplied, without the need to perform any of the other steps.  There are plenty of details to work out here; I think that the granularity of the versioning is a bit too broad right now, for instance.  But I think the idea is a good one.

Not everything that needs to happen during a reinstall or a migration can be represented effectively by a setup profile,
however.  Florent Guillaume gave a good example when he described a site that had both News Item and Press Release content types, but which decided they were redundant and wanted to merge them.  The setup profile would indicate that there was no more Press Release content type, but there would be no way to specify that the two types had actually merged, and that the existing Press Releases should be switched to News Items.  Nuxeo has handled this in an elegant fashion in CPS, by introducing a new ZCML tag (<cps:upgradeStep>) that registers a checker method to verify whether or not the upgrade step needs to happen, and another method which actually performs the upgrade.  You can see more about the CPS implementation of this, and a much more low-level description of GenericSetup and how to use it, at Florent's excellent GenericSetup blog post.

I think that by fleshing out the import step versioning implementation, and taking the upgrade step idea that CPS has
implemented and putting it into the GenericSetup core, we would have a good set of tools with which to replace Plone's current product installation and site migration infrastructure.  It is also worth noting that the migration infrastructure would work equally well on base and extension profiles, so all add-on products would be able to use the same migration strategy, instead of having to implement their own migration mechanisms as they are forced to do now.

This is not the only possibility, however.  I know that Zope3 uses something called "generations" for it's migration needs.  I don't know enough about how it works to be able to compare its suitability for Plone, however.  I'd love to have a chat w/ someone who understands both generations and Plone, to try to see if we can agree on a best solution.  GenericSetup is already, as of Plone 2.5, integral to Plone's site creation process, however, so unless generations turns out to have a radically different and superior approach, I'm currently leaning towards working on the implementation I've described here.

Chris Calloway writes with news of TriPZUG's upcoming Plone Bootcamp 2, behind held March 13-17 in beautiful Chapel Hill, North Carolina.

I'm gonna publish the rest of his note to us, mainly because it's a hoot.  Clearly this man has studied at the Alan Runyan School of Stream-of-Conciousness Writing. ;-)

This is the second year TriZPUG has hosted Plone Boot Camp. We like to think we paved the way for DC and Seattle and Boston and New York and the other places which have done it or are planning to, although they probably would have done it anyway seeing how Plone is like my new filing technique: unstoppable.

We have the amazing Joel Burton again, who might be world's greatest technical instructor from what I saw last year. Anyway, we see the Seattle camp is sold out.

PBC2 is the week after Plone Symposium, because that's when we could get the high tech classroom.

So, I'm not above begging you to please plug us on your mighty blog. You'll be glad you did. Secret angels in heaven will protect you for your kindness. CMFMember to membrane migration scripts will magically appear out of thin air. PloneBoard will be fully funded for whatever it is it needs funds for. If you'd like, we can arrange to have a daily Plone Blog entry from Plone Boot Camp 2.

Nate Aune, Tom Parish, Tom Lazar and over 20 other folks have kicked off a great conversation about the future of blogging in Plone.  It's leading in some interesting directions... how best to factor out core "blogging" functions such as syndication, trackbacks, aggregation, etc. into generic Zope3-style components so that they can be used across Plone (and beyond!)... how to improve Plone's library of freely available skins... and more.

If you're interested (as I am), in Plone as community collaboration software, this is the conversation to tune into.

A few months back, my friends Marshall Mayer, Brian Gershon and I commiserated over a beer here in Seattle about the lack of robust, reliable, modern, moderately full-featured forum software for Plone.  Marshall runs LiveModern.com, and has one of the world's larger CMFBoard installations, which has become a clunky and and unwieldy beast.  (See Marshall's comments below.)

"Wouldn't it be great," we thought, "if Ploneboard could be full-featured enough to be a solid general purpose discussion forum tool?  It's got a solid architecture, great developers -- all it needs is a bit of a push."

So we got out our notepads, threw together some PLIPs, and started some conversation with the Plone community about what Ploneboard needs.  Then we got online with the Plone Solutions gang to hash out what was feasible, what should be prioritized, and what it would cost to get it done.

Marshall and the LiveModern community are putting up some of the dough.  We're trying to raise the rest from the wider Plone community.  You can make a pledge now at Fundable.org, or you can contact Marshall directly at marshall at LiveModern.com.

There's another angle as well.  For me, this effort is not just about Ploneboard.  It's about piloting a more general process for funding and supporting products and features in Plone. 

As we all know, great open-source software projects (like Plone and its products) don't "just happen."  Some things happen because there's a single customer who has a need and the means to pay for it.  Some things happen because a developer (or two) have a huge passion for a good idea and are willing to burn the midnight oil to make it happen. 

But  there are some needs out there -- like the need for a great Plone forum product -- that a lot of folks need,  but no single user has the pain and the cash to single-handedly fund the development work.  And there's no developer who is willing or able to "just do it" for free at a sufficiently high level of quality.  It's an "open-source market failure," if you will.

So, here we are with Ploneboard, experimenting with one possible solution to this dilemma:  a "social source" development model where a community of users come together to define their spec, raise the money, and fund the development process.  It's a big experiment, but I think the Plone community is strong enough that it can work, and I hope that our efforts can blaze a path that we can all use in the future to fund additional work on important Plone features that no single customer can justify funding.

Here's the meaty part from the email Marshall just sent to plone-users:

I've used CMFBoard for a couple of years (my name was even in the  
credits at one point), and it's just not a product that I want to  
stay with longer term. There is no documentation or support, it's  
unclear if it will ever be upgraded, and while it is full featured it  
just does not scale well (it follows it's own path, and unless  
CMFBoard 2.3 is a complete rewrite -- a HUGE task -- I have no  
confidence in that path). It's time for a change, at least for me.

Ploneboard, on the other hand, seems to me to be the future, and if  
it takes off like it should it could even replace the discussion tool  
in Plone. It's quite simple (it will never be full-featured, by  
design, though you could add your own features to it), it does most  
of what a discussion board should do really well, and most  
importantly Ploneboard is written to work well with Plone 2.1.x  
(i.e., it is architected well, scalable and it does not break  
anything else).

While in development for some time, Ploneboard 0.1beta1 was released  
less than 6 months ago, I think mostly to show that there was a there  
there. It looked promising. Plone Solutions is now working on a major  
upgrade to Ploneboard, funded by clients and the community.  
Development is being driven in part by a PLIP,

http://plone.org/products/ploneboard/roadmap/psc_improvements_listing

that was generated by some of us CMFBoard users with the most pain.  
Note that there is a PLIP for a migration utility (deferred until  
after the next version comes out), and that some PLIPs are in  
progress (the ones we think are necessary first steps to get a good  
product out quickly). Other PLIPs are possible, but will depend on  
funding. It's been great working with Plone Solutions to develop and  
flesh out the PLIP.

My site, livemodern.com, is paying for some but certainly not all of  
this work. Much like Morten, I'm raising money from my members to  
help fund the development of Ploneboard. I've set a goal of $2500 USD  
to be raised in the next month. Part of that will be raised using  
another cool Plone site, http://www.fundable.org .

If you are using CFMBoard and want to migrate, help us get Ploneboard  
to the next version as fast as possible. Contact me directly if you  
want to contribute. If you want your members to contribute, set up a  
fundable.org campaign. Heck, if you simply want to get Ploneboard  
moving along, contribute now at

https://www.fundable.org/groupactions/ploneboard

Either way, it's time to contribute to a discussion board solution.

Marshall Mayer
marshall at livemodern.com 

It's not too often that I look at the demo for a new Plone product and think, "damn, that is freaking cool."  (This probably says more about my native cynicism than the average Plone product.  But I digress.)

 I just checked out the demo for Flay, and I have to say, it is pretty darn cool. According to the creator, Dr. Michael J. Chudobiak, Flay "generates a simple - but productive - web interface for Posgresql databases."  Basically, it's like a little version of phpMyAdmin, the popular webadmin tool for MySQL databases, only for Postgres and Plone.

I could see this being really cool for anyone who's linking Plone to relational databases, and wants to make it easy for users to do some "back-end" editing of those database content from within Plone. 

With all the chatter about Plone/Zope's "RDBMS story" of late, I think this is a neat little piece of the puzzle.

Munwar takes note of a new article by Raven Zachary in Enterprise Open Source Journal titled "The Prince and the Golden Egg."  You can read a "digital magazine" version at ESOJ, and Munwar's got a more manageable PDF version.

It's a worthwhile read not only because it tells the Goldegg story and shines a bright light on the maturity, diversity, and capability of the Plone community, but because it also encapsulates other open-source fundraising stories, including this summer's Drupal development server fundraiser, DadaMail feature fundraising via Fundable.org, the SpreadFirefox effort, and others.

Zachary concludes:

When open source project team members are sacrificing their time and resources to advance a project, and for-profit organizations benefiting from their work are not participating in the support of the project, something is out of alignment. It’s in the best interest of a user—whether an individual or an organization—to support open source projects they are dependent upon. Goldegg was an example of fund-raising in the form of a community/customer partnership.

I believe we will see more such examples of partnerships in the future. We need to look at the issue of open source project fund-raising as a key aspect of supporting open source projects, in their various states of maturity. And we need to turn to both the large community of individual donors and the for-profit organizations that directly benefit from the use of open source software.

More succinctly, I think the larger question is: how do open source software communities develop efficient, effective processes for aggregating the needs of our users, and developing the resources to fund efforts for which the demand is diffuse  -- i.e., where there is no single customer who can afford to pay the full cost of the project?

Snow Sprint 2006 looks like it was big, fun and successful.  I'm sure that many folks are sleeping off jet lag or other forms of fatigue.  ;-)

But, if you did something cool or noteworthy, don't forget to write up a little note about it.   Put it on the developers list, put it on your blog, write about it here -- it doesn't really matter. 

Props to Reinout van Rees and Rob Miller for great examples.

Over the last 4 days here at 2006 Snow Sprint I've been working on a refactoring of Helge Tesdal's Membrane product.  I think this is important work for Plone, and am very excited about how it's coming along.  Here's a brief overview:

Membrane is a product that allows regular Archetypes content objects to provide the information needed for such user-related tasks as authentication, group membership, user properties, and more.  Anyone who has used CMFMember can speak to the value of using content to represent members.  Workflow becomes a valuable asset in managing site security and member management.  AT schemas are the means to manage member properties, allowing developers to use the auto-generated view and edit templates and AT's rich field validation engine.  Member searches use a catalog.  But anyone who has used CMFMember can also speak to the fact that it is complex, confusing, and somewhat scary.  There are many factors contributing to this, but one of the biggest, IMO, is the complicated user wrapping approach that CMFMember inherits from Plone and the CMF.

How does Membrane improve on this?  Most Plone developers have heard of PAS (i.e. PluggableAuthService) and PlonePAS by now.  PAS is the successor to old school user folders that allows all aspects of user management, including authentication, user properties, group and role management, and more, to be delegated to plug-ins.  PlonePAS is the product that reimplements the standard Plone behaviour using PAS instead of GRUF.  Membrane is a collection of PAS plugins that allow this important information to be retrieved from AT objects existing in your portal.

This is the crux of the distinction: with CMFMember, content member objects wrap persistent user objects, and it is
necessary (and sometimes difficult) to maintain synchronization with the user object.  With PAS, user objects are created dynamically upon request, and with Membrane, the content member objects are BEHIND the user object.  A developer will ask PAS for a user object, PAS will delegate to Membrane, Membrane will retrieve the appropriate content object(s), and will return the appropriate information to PAS.  If Membrane determines that authentication fails, then the user object is never created, no muss, no fuss.

What I have done is refactored Helge's original product into smaller pieces using Zope 3's component architecture.  Originally, if you wanted to use content as a member provider, you would need to subclass your content from a number of different mix-in classes provided by Membrane.  Now all of this behaviour is handled with adapters.  It is possible to use ANY piece of content as a member provider, as long as it implements (or can be adapted to) a very simple interface that Membrane provides.  Similarly, any content can be used to provide properties or specify group membership.  In fact, multiple pieces of content can be used for these purposes.  The default implementation uses a specific reference class to define relationships between these various objects, but since this is componentized it is absurdly easy to replace with any implementation of your choosing.  In fact, nearly EVERY piece of the product is easy to replace with a custom implementation.  It takes a while to wrap your brain around working with adapters and components, but the value of it quickly becomes clear when you realize how loosely coupled the results are, if it is done correctly.

This technology is still very new, of course; this is not road tested, and there are some known gotchas that early adopters should be aware of (see the readme).  And it requires you to be running the Zope 2.9 branch and the Archetypes 1.4 branch from svn, neither of which are officially supported with Plone 2.1.  It's coming along very well, however, and I am very hopeful that this will stabilize quickly and will become Plone 3.0's default member implementation.  This is definitely the forward path for CMFMember; not only is this a much better solution, but the changes that PAS introduces to the low-level user object behaviour mean that CMFMember will not work with PAS at all.  Instead of putting effort into making CMFMember work, I plan on providing a clean migration path forward to a Membrane-derived solution.

Membrane can currently be found in the collective subversion repository.  The componentization work is available on the "adapterizing" branch.

The 2006 New Orleans Plone Symposium will be this March 8-10, 2006 at the Astor Crowne Plaza in the famous New Orleans French Quarter. The goal of this year’s gathering is to share ideas on relevant topics through discussions around the pragmatic usage of Plone and real-world experiences of organizations like Disney and fundable.org. While technology is always the core focus of open source technology events, this year's symposium will also addresses specific business topics including law, non-profits, venture capital and business models.

“The New Orleans Symposium aims at being the top open source content management conference in North America for 2006”, Says Alan Runyan, President of Enfold Systems. The event will host two concurrent sessions – one track focusing on business, and the other on technology. The first day consists of 3 hour tutorials on topics from Plone best practices to implementations at non-profits. The next two days utilize 45 minute talks ranging from Enterprise Search strategies to Content Delivery options.

Andrei Codrescu, the noted writer and commentator, will close the symposium. Known for his unique insights into society and human nature, his thoughts on the open source community and its future promises to be both thought provoking and entertaining. Like a great cup of gumbo, the rich mix of applied business and technology topics should make this year’s Plone Symposium a memorable event.

2006 marks the fourth year of active deployment for the Plone Open Source community. To encourage and cultivate the community spirit, daily post-event socializing is scheduled for the world-renown New Orleans Vieux Carre (French Quarter). In fact, over 90% of last year’s attendees indicated they would return and encourage others to come as well.

For more information:

Symposium homepage: http://plone.org/events/regional/nola06

Talks schedule: http://plone.org/events/regional/nola06/talks

Tutorials Schedule: http://plone.org/events/regional/nola06/tutorials

Registration: https://www.enfoldsystems.com/conferencereg.html