“The software is an artifact of the community.”

One of the memes I heard on the breeze at Plone Conference 2006 was something I heard attributed to Paul Everitt, co-founder of Zope, incoming Plone Foundation board chair and all around nice guy. (Who needs to blog more often, hint, hint!)

The software is an artifact of the the community,” Paul is alleged to have said. Damn. I wish I had thought of that. It’s not only short, memorable and true, it’s true in that “illuminating a deeper and easily-overlooked truth” kind of way.

Plone, the software, is the artifact of Plone, the community. Plone doesn’t exist in a vacuum. It the collective product (and gift!) of a community of people. Plone, the software, reflects the skills and passions and energies of Plone, the community. (It probably also reflects our collective neuroses and dysfunctions as well!)

Paul’s observation invites us to see open-source software through the lens of the communities that create it. It suggests that to really understand Plone, you need to spend the time to understand the Plone community as a community.

Plone has a history and, as I’m beginning to learn, a culture. Martin Aspeli’s master’s dissertation is a great social history of Plone through mid-2005, and Martijn Faassen’s talk at DZUG 2006 is a really informative longer-term history of Python, Zope and Plone. But of course, most history is oral history, and I learned a ton about where we’ve been (and where we might be going) from talking with Paul, Alexander Limi, Joel Burton and others at the Plone Conference. That’s one of the many, many reasons that in-person gatherings are so important for vital communities.

More importantly, if you care about the future of Plone the software, you need to think about taking care of Plone the community — and the individuals and organizations that make up that community. Plone the software will continue to evolve and succeed only if the community of people that make and use Plone are happy, healthy and passionate about what they’re doing. That means making sure they have good projects, sustainable employment, opportunities to share ideas with each other (and to borrow good ideas from elsewhere), and ways to be recognized for their contributions.

Innovation and Knowledge

Another great post from Dave Pollard, this time summarizing the key processes that lead to innovative organizations.  With fun charts!

Innovative organizations are constantly scanning broadly for new ideas that can be adapted for innovative purposes. Their ‘information professionals’ job is to ‘make sense’ of the information from both primary (interviews and surveys) and secondary (Internet and information media) sources. These organizations share what they learn as a matter of course, in the knowledge that sometimes brilliant innovations come from serendipitous learnings. And these organizations engage their customers in continuous dialogue, to co-develop solutions through a knowledge exchange of needs and ideas.

Writely Reopens

Writely, the web-based word processor that Google recent purchased, has re-opened to the public, for free.

It’s not quite a replacement for Word, but it’s a damn handy tool for writing documents collaboratively.

Collaboration That Works at ONE/Northwest

A while back, I promised to write a bit more about some of the practices we use here at ONE/Northwest to collaborate amongst our staff of ~13 scattered across three offices. Here’s a first installment.

Building awareness and transparency

For our first few years, we were 4- 5 people crammed into about 800 square feet with no doors and no walls. So it was easy for each of us to be aware of what the others were up. Perhaps a little too easy; my former colleague Eva, who sat two fee away from for 8 or 9 hours a day, used to call me her “day spouse.”

Now that we’re larger, simply maintaining a solid awareness of what we’re all up to is a big challenge. And it’s absolutely critical, because there’s very little work we do that doesn’t require collaboration amongst two or more people. Even worse, we’re constantly changing and improving *how* we do things, which means that we need to rapidly spread new ideas throughout our organization.

Here are two things we do to promote a culture of transparency and awareness:

1) Weekly plans.
At the beginning of each week, each of us takes 15-30 minutes beforetackling that pile of email to write up a short plan for the week ahead. Our plans are all in the form of a table with the following columns:

Project | Moving Part | Outcome | Staff Involved | Priority | Completed?

The purpose of this plan is to for each of us to reflect a bit on what we need to accomplish this week and who we need to work with in order to get it done. We then publish our plans on our internal wiki site and circulate them to all staff via email.

Weekly plans have turned into a great focusing device for us indvidually, but they also help us maintain “team awareness” that’s critical to letting us tackle complex, fast-moving projects together.

2) Today Messages

The Weekly Plan’s little sister is the Today Message. At the end of each day, we take about five or ten minutes to record our major tasks for the day in our time tracking system (which is powered by DotProject). We click a little button in DotProject, and it generates a short email that summarizes our day in bullet points. We then email that around, thereby providing our teammates with a quick summary of what happened in our lives that day.

Again, it’s simple, fast, and high value.

Real-time communication

3) Skype

We’ve become really addicted to Skype — free, online phone calls and instant messaging. Unlike most of its peers, Skype is cross platform, requires zero setup and is extremely easy to use. We use it to send each other instant messages, and as a substitute for the telephone. Not only does it save us a bundle on inter-office long distance calls, it makes it really easy for us to ask each other quick questions without the interruption of phone call or the clutter of email.

We also use Skype a lot to communicate with our far-flung network of consultants and peers.

Project Management

4) Basecamp

We use Basecamp, an inexpensive web-based project management tool as a lightweight project management (task tracking) tool. It’s quick and simple, great for short-term projects with multiple people including some folks from outside the office. It’s not great for complex, long-term projects.

5) DotProject

We keep a lot of our long-term information, including our time tracking data, in DotProject, a powerful, flexible open-source project management tool. Its UI is a little clunky, but it’s got a great model for tracking time.

6) Salesforce.com

We use Salesforce.com as our internal database of people and organizations. Salesforce has some amazing reporting tools, so we actually use it to build detailed reports on our DotProject task data.

A Peek Under the Hood of Open Source

Jonah Bossewitch’s summary of this month’s Big Apple Sprint is a great peek under the hood of what effective community-driven open-source development process looks like.

Big Apple Sprinters

I also think that the substance is pretty compelling to nonprofit website builders, because it’s all about “that Web 2.0 stuff” like multimedia, tags, blogging and creative commons licensing.

Here’s the meaty part of Jonah’s summary:


Multimedia
– focusing on improving the handling of multimedia
content w/in Plone. Topics included transparent management of multiple
media formats, improving the quicktime player, abstracting the common
controls from the different media player formats, merging Austria’s
ATVideo bittorrent branch, allowing for remote resources to be managed
by the media types, and the integration of CCNMTL’s video clipping tool into
PloneMultimedia. Thanks to Nate, Gary, Anna, Kurt, and Sky for making this group a productive success.

Discussions emerged around the hybridization of modern media formats.
Is an audio track with synchronized gifs a piece of audio or video media?

A new ‘media’ container was introduced to PloneMultimedia allow for the mgmt of media that spans multiple traditional formats.

Annotations/Tagging – laying out the jigsaw puzzle that tagging, rdf, taxonomies, folksonomies, and sticky notes, and microapps have become in the hopes of consolidating on a common strategy to move forward. The Yucca
project was born after we all began to realize how many of our problems would naturally fall into place with a robust engine which supports user contributed
content annotations.

Also, work was done by Anders and Chad on the sticky notes product with the aim of factoring out the notes so they could be used outside of plone too (with the persistence abstracted, so that it could be backed by a microapp – like pita, or even stored client side), as well as improving the editability of the notes – they now support “double-click to edit”. Great job!

Blogging/Syndication – This group (Rob and Kurt) was primarily working on polishing quills so that it provides a smooth user experience. Progress continues and Quills is looking like a serious contender.

Content Licensing – see Nate’s post on conetent licensing in plone. This work was conducted primiarly by the group working in Utah, out of C()SL.

In case its not obvious, there was a great deal of overlap between the interests of the groups. For example, the multimedia team was also very interested in tagging, syndication ((p/v)odcasts), and licensing. Although it initially seemed challenging to tease the participants apart, the groups self organized quite organically.

The sprint was very productive, educational, and great fun as well. Beyond the technical achievements, relationships were forged that we expect to flourish in the months to come. I think we all witnessed tremendous convergence across our organizational requirements, and are also convinced that the tools we are working on will be in great demand once the corporate world figures out how useful these technologies can be.

Single Stacks, or Network-Centric Web Services?

Reading Zack Rosen’s assertion that building applications inside Drupal-the-framework makes more sense than loose integration of complementary applications triggered some thinking that’s been rattling around in my head for a while.

I think that the next few years are going to bring tremendous challenges for applications that do not easily communicate with other applications that are “outside their platform” i.e are written using a different language/framework, run on a different server, etc.

I think the most powerful path forward over the long haul is internet-based integration between great applications that were designed from the ground up to allow for it. 
In other words, web services APIs are going to become increasingly more important, and the particular application frameworks less so.  This the “small pieces, loosely joined” model, to echo the phrase that others have appropriated from Dave Weinberger’s influential book.
There are some great communities and significant resources behind very cool projects that provide great functionality that I really want to be able to tap. I don’t want to have either persuade them all to develop in a single platform (it’s just not going to happen) or try to duplicate all of their functions in whatever platform I’m most comfortable in. (Which, truth be told, is “none of them.”)

My colleagues here at ONE/Northwest and I would much rather focus on integrating best-of-breed applications that have strong web services APIs and are designed around the assumption that external applications are first-class citizens of their ecosystems. (Damn, that’s a lot of buzzwords.)

At the end of the day, why should I have to care if an application is based on Python, Zope, PHP, Rails, Django, or some technology I’ve never heard of? Why should I have to run all my applications off a single server? That’s not scalable. We now have a whole set of standards and technologies to let applications communicate with each other over the internet.

“Web services” is one of those complex, slippery terms that means lots of different things to lots of different people. To me, in this context, it means applications that share data with other applications over the internet. The more of your application’s guts it can expose to the outside world, the more powerful your web services API.

Some applications that I think are really moving in the right direction with web services support are:

  • Democracy In Action — powerful API, alas, not yet well documented. Little known fact: the smart guys at Enfold Systems have releaesd a Python wrapper for the Democracy in Action API, which (supposedly) makes integration with Plone possible. Haven’t tried it yet myself. But I’m looking forward to it.
  • Salesforce.com. Holy cow, these folks really get it. I’ve heard that half of their traffic is through their web services API. This is how a relationship management database should be — accessible by most any external application.
  • WhatCounts. These guys do our email blasting. Lots of folks do email blasting, some probably just as well as WhatCounts. But what sets WhatCounts apart from the pack fo us is the fact that they have strong APIs. This lets us do cool stuff like pull in names from Salesforce, or inject new subscribers from Plone, or pull in content from a Plone site. (Well, technically pulling in content from the outside doesn’t use their web services API. But the point is that WhatCounts can pull in data from outside and let other apps push data in.)
  • Another, less strictly “web services” example is Plone’s new PlonePAS framework. Basically, it’s a framework for authenticating users and retrieving user data from any old data source you’d care to write a plugin for. We’re going to try to use it to integrate Salesforce.com and Plone.
  • The whole open-source GIS software ecosystem, most especially including MapServer. My next-door neighbor, Chris Davis of CommEn Space, has shown me some really mindblowing stuff with maps that dynamically draw in data from all over the internet, thanks to open data standards and web services.

Can you see an advocacy software ecosystem here yet? I can.

And let’s not forget all the “Web 2.0” applications out there that are getting so much hype these days. One important thing about the most exciting of these tools such as Flickr and Del.icio.us is that they can be written to and read from by outside applications via web services APIs.  (Amazon has done amazing stuff here, too, albeit without getting much “Web 2.0” credit for it.)
This is where it starts to get cool. The days of monolithic application stacks that try to do everything are fading fast. A new “network-centric” software ecosystem is starting to bloom.

And the best part: nobody has to “deeply partner” or adopt a single platform to make it work. They just have to focus on building great web services APIs so that other applications can meet them halfway. That’s not easy, but it’s surely easier than getting everyone to adopt the same platform.

Some software tools that I really hope build strong web services APIs as they roll out their next releases include:

  • Green Media Toolshed
  • CiviCRM (their web services API work seems to have stalled out in favor work on a PHP API that only talks to a PHP application (like Drupal) installed on the same server. Hopefully their focus will soon return to playing with the outside world, too.)
  • Custard Melt
  • Advokit
  • All of those nonprofit online donation tools that I am too tired to list right now. You know who you are.
  • And, yes, Drupal, too. 😉

I’m probably overlooking some other apps that ought to be listed here. Feel free to suggest them. It’s late.

The Permeable Nonprofit

Michael Gilbert writes about the trends in networks and communications that he hopes will create “The Permeable Nonprofit”:

The key to our transitional thinking will be a new mindfulness about organizational boundaries. We will adopt narrower definitions of corporate control over communication. We will recognize richly permeable boundaries as valuable assets, rather than liabilities. We will turn our organizational borders into gateways to empowerment. We will pull back our boundaries from many resources and learn to husband them as they grow, rather than own them as they shrink.

In the long run, we will probably have to let go of the corporate model itself, as the dominant form of organizing in civil society. Among our older models, collectives and cooperatives are much more suited to the task and to the new environment. New ways to form ad hoc groups are emerging and new ways to form coalitions are desperately needed. And there will be models for which we do not yet have names.

Bottom line: lots of assumptions about how nonprofits should be structured and should do their work are being undermined by modern communications systems.

Nobody knows what the new models will look like, but it’s increasingly clear that we need to start the experiments that will help us learn enough to grow beyond the 1970’s “direct mail” membership models that so many groups adopted during an age of centralized media and snail mail.

Michael Gilbert’s Three Wishes

My friend Michael Gilbert has three wishes for 2006:

I have three wishes for the nonprofit sector in 2006. I hope you will help me make them come true. In brief, my wishful thinking is this: (1) Mainstream leaders across US civil society wake up to the fact that the fundamental underpinnings of our sector are being destroyed. (2) The traditional silos and boundaries of nonprofit corporations loosen and open enough to take advantage of the power of networks. (3) Those who concern themselves with innovation in the sector will stop confusing it with hipness and will start investing in true structural enablers of new ideas.

I would love to hear Michael elaborate on these wise, provocative and somewhat vague wishes.

A big challenge: building new work habits for a networked world

At ONE/Northwest, we’ve been doing a bunch of experiments with different techniques for managing ourselves and our work, techniques designed to help us continue to be a nimble, flexible, effective and happy team as we have grown from 8 to 12+ over the past couple of years.

We’re using tools and techniques like instant messaging, VOIP, Wikis, blogs, RSS feeds, Today Messages, Weekly Plans, dotProject, Getting Things Done, Salesforce and more. Not to mention good old fashioned face-to-face meetings

But the biggest thing I’m learning from all of these experiments is how much there is to learn about how to work effectively in a complex network of poeple and information. And I’m realizing that progressive movements are going to need to invest a LOT more resources into teaching our people how to work effectively in this new kind of environment. It’s not obvious, it’s not intuitive, and while the tools are powerful, it takes some experience to wield them.

Update: More on our experiments coming soon, I promise. In the meantime, feel free to chime in with your collaboration frustrations. What keeps you from working most effectively with your colleagues, both within and outside your organization?

Call Me a Skeptical Turk

Ok, I’ve thought a bit about Amazon ‘s Mechanical Turk service. It’s a platform for folks to write computer programs that need small amounts of work from human beings as part of their input. You supply some cash. Amazon supplies the people. The people supply the thinking. Very, very clever.

Marty and Brian are very, very excited. There are some neat things that one could do with this — like building a media contact database, or transcribing audio and video recordings.

But as I read the initial wave of blog posts about the Mechnical Turk, I notice a distinct scarcity of interesting ideas for how to actually apply peer production to organizing and/or advocacy problems. The skeptic in me can’t help but wonder: how many organizing and advocacy problems are really out there that can be solved by small bits of labor from many unskilled people in front of their computers?

I’d like to see more ideas about important problems that could be solved with this approach. I just can’t think of many. Maybe I’m just blocked. Or maybe there’s less to be excited about here than we might wish to think. Or maybe it’s 12:45 AM and I should just go to bed.

How Plone Can Become Kick-Ass Community Collaboration Software

The quality and power of Plone as a content management system is incredible. It’s got incredible usability, workflow, permissioning, document handling, search, extensibility, internationalization, accessibility — and more. We’ve launched over 40 Plone-powered sites for non-technical clients in the past year with a very small team of people.

However, for websites that revolve around “community” and “collaboration” (whatever those things mean, and believe me I’m often very cynical) I think that Plone’s community collaboration features could use some improvement.

The good news is that most of these features have pretty solid products that already get us 80% of the way there — they just need some focused “polishing.” Here are some thoughts drawn from our experiences at ONE/Northwest, and some of my hopes for the future.

But before I dive in, I apologize in advance. These are all pretty raw thoughts, and there’s likely a lot of half-baked ideas and not-so-great conclusions in here. I thought it better to spit this out into the world to see what response it would attract than to spend too much time polishing it to a sheen.

Continue reading How Plone Can Become Kick-Ass Community Collaboration Software