• Common agenda.  If you don’t have a shared vision for change, you can’t really expect to collaborate effectively.
• Mutually reinforcing activities.  Successful collaborators need to coordinate their activities, play to their strengths, and know their role in the larger effort.
• Continuous communication.  If you don’t communicate regularly you can’t hope to build enough trust and shared language to collaborate effectively.

At this point, you’re probably thinking, “Jon, why are you wasting my time with such obvious folderol?”  Most coalition efforts I’ve seen fulfill these first three conditions pretty well.  Hang in there, it’s the next two that are the most interesting:

• Shared measurement systems. Hmm, now we’re getting somewhere.  Collective impact suggests that collaborative efforts need agree on a shared set of indicators of success and the systems for monitoring and reporting on those indicators.  Without shared indicators, collaborators have no way to really know if they are succeeding or failing, and no feedback systems that allow them to “course correct” as needed. 
• A backbone support organization.  Proponents of collective impact assert that successful collaboration efforts need to have a strong, staffed organization at their center, in order to run the collaborative process with sufficient intensity and focus to drive it forward in the face of distractions.  It’s not clear to me whether they think a strong “lead coalition partner” fulfills this condition or not.  (I suspect not.)

It’s these last two points where most collaborations falter, and probably not concidental that they require sustained, long-term resource commitments.  How do collaborations you’re involved with stack up?

The No-Fun ZopeSkel BBQ Sprint accomplished 23 major tasks in four days primarily by four sprinters. We are very excited by the productivity and usefulness of the sprint and feel there are some lessons to impart:

• Smaller sprints are by far more productive.
• Ruthlessly focused sprints are more productive. Having super-clear goals and not wavering from them is key.
• Excluding topics which don’t exactly fit goals is not a bad idea.
• Design discussion and documentation ahead of the sprint make for a more productive sprint.
• Inviting capable sprinters with strong motivations and undivided attention is abolutely necessary.
• Bounties are not all they are cracked up to be. They take a lot of work. There may be easier ways to raise travel expenses.
• A work environment geared towards serious concentration with no interruptions or distractions is extremenly helpful.
• Starting as early as feasible each day and working for about ten hours is most productive.
• A lunch break which involves walking to a location away from the work environment refreshes the afternoon’s work.
• IRC, Twitter, UStream and other open communication channels are distractions while sprinting. Help yourselves before helping others outside the sprint while it is sprint-time. There will be time to help others after the sprint and a sprint which doesn’t produce helps nobody.
• Sprint now, report out later. Blogging is another distraction while sprinting. Help the sprint first.
• Photographing whiteboards is a nice security blanket which doesn’t take much time.
• Have the network set up the day before. Don’t go wireless. Have a high speed switch on a fat pipe.
• Have a couple of nice dinners in the middle of the sprint. Make lunch fun. Eat BBQ every day. Have BBQ on your pizza. People who have fun together work together better.
• Get plenty of sleep. Don’t stay out all night.
• Get the nicest possible accommodations. Private accommodations entirely taken over by the sprinters are best.
• Do not fit three people in the front seat of a pick-up truck.

There’s a lot of clean-up work left over from this sprint. We could have used an extra day. It would have been wrong to cut short the work being completed on the final day in order to make a second ZopeSkel release in four days. Plus, some clean-up work depends on the outcome of discussions regarding the previously mentioned splitting proposal. Suffice to say, there will be at least a couple of people merging branches into trunk at the Plone Conference 2009 Sprint.

Previous posts about sprinting:

Sprint Wisdom

More Sprint Wisdom

What good is funding campaigns to send faxes, emails, tweets, phone calls and letters to legislators who are already overwhelmed by unstructured incoming messages?  Why not also work on tools to help the legislators track and manage inbound communications more effectively, so that they can actually hear the voice of organized people over the din of organized money?

Why not invest in providing government with the tools to run proper community engagement processes that bridge traditional in-person public meetings with online technologies?  This probably requires some interesting innovation in online discussion tools.

Most social change advocates believe fundamentally that government works.  Why don’t we systematically invest in helping it transform itself so that it can be more open and responsive to our advocacy?

Let me close with a final surprise, that’s more of a disappointment. I certainly expected that, by now, online tools for conversation, work, collaboration and discourse would have become far more useful, sophisticated and effective than they currently are. I know I’m pretty well alone here, but all the glossy avatars and video and social network sites conceal a trivialization of interaction, dragging it down to the level of single-sentence grunts, flirtation and ROTFL [rolling on the floor laughing], at a time when we need discussion and argument to be more effective than ever. Indeed, most adults won’t have anything to do with all the wondrous gloss that fills the synchronous online world, preferring by far the older, asynchronous modes, like web sites, email, downloads etc. This isn’t grouchy old-fart testiness toward the new. In fact, there are dozens of discourse-elevating tools just waiting out there to be born. Everybody is still banging rocks together, while bragging about the colors. Meanwhile, half of the tricks that human beings normally use, in real world conversation, have never even been tried online.

The following essay summarizes our experiences and attempts to tease out someulearnings both for nonprofits and for Open Source communities

This is a really rough first draft. I invite your thoughts, feedback, questions and criticisms. Tell me what parts (if any) ring true with you. Tell me what to cut. Tell me what I missed, or what I just plain got wrong.

Introduction

The goal of this essay is to discuss:

• My experiences as a nonprofit, non-programmer consultant joining an existing, thriving open-source community.
• How I was able to contribute to the community and build social capital in it.
• What nonprofit people are good at; what open-source software developers are good at; what we can learn from each other, and how those things are complimentary.

Over the past two years, I’ve spent a bunch of time a bit outside of my “home base” in the Pacific Northwest environmental NGO community. I’ve been hanging out (both in person and online) with a community of open-source software developers — the Plone community. (Plone is a popular Open Source content management system; it’s software that nonprofits — and lots of other folks — use for building powerful, interactive websites.)

Jumping headlong into a thriving community of brilliant Open Source programmers has been a fascinating adventure. I’ve learned a lot about Open Source, about working with programmers, and about the nonprofit community as well.

Of course, what you see depends on where you stand, so I should probably start with my background. I’ve spent the past 11 years at ONE/Northwest (www.onenw.org), helping nonprofit environmental advocacy organizations figure out how to harness the internet for social change. Along the way, I’ve learned a lot about technology (my mom thinks I’m a computer whiz) but I’m not a programmer. My degree is in political science and most of my skills are in project management and communications strategy. If I wasn’t doing this, I’d probably doing political organizing.

ONE/Northwest’s Experiences in the Plone Community

The web is a powerful communications platform for nonprofits. Its global reach and low barriers to access make it an key part of any organization’s online communications toolbox. But building powerful, professional, easy-to-use websites is still quite challenging, technically and otherwise. The rapidly increasing power of web systems over the past decade has only increased the challenges facing small organizations with limited in-house technical skills.

In mid 2004, it occurred to us at ONE/Northwest that an emerging class of Open Source content management systems, which large enterprises had been using for several years, might well be good enough and easy enough to use for smaller nonprofits. After evaluating a number of content management systems, including Plone, Drupal and Joomla, we chose Plone as the ideal platform upon which to base a pilot program for building a new generation of low-cost, feature-rich, easy-to-use nonprofit websites.

All modesty aside, we turned out to be spectacularly right. We quickly found that Plone let us easily build impressive websites for the nonprofit environmental groups we serve. We could customize Plone to meet the widely varying needs of this diverse community. We could continually re-use bits and pieces of software we developed, and even better, Plone’s ease of use meant that environmental activists with very limited technology skills could maintain and update their websites without any outside help.

But something else happened.

Plone isn’t just a software product. It’s a community. A global community of smart, passionate, dedicated people who have come together around a shared vision. And by choosing to use Plone-the-product, we soon realized that we were choosing to join Plone-the-community as well. And that’s the real subject of this essay.

Within 18 months, me and my colleagues at ONE/Northwest went from wet-behind-the-ears Plone newbies to key leaders in the Plone community. How did that happen? What lessons can we learn about Open Source and nonprofits from our experiences?

It all started with something that came naturally to us, as technology-savvy environmental activists. Once we’d gotten a few projects under our belts, we started blogging about our work with Plone. We talked about how excited we were about it, what was going well, and what we thought could be improved. Before long, our writings caught the eye of the Plone’s co-founders, Alan Runyan and Alex Limi. Alan was in the midst of planning the 2006 North America Plone Symposium, and one day in February 2006, my phone rang.

“Hi Jon, this is Alan Runyan, how’re you doin’?” drawled a friendly southern voice. (Alan’s from Texas by way of New Orleans.) I cupped my hand over the phone and stage whispered across the room to Andrew Burkahlter, one of our Plone programmers, “It’s Alan Runyan on the phone!” Alan continued, “Hey, it sounds like y’all are doing some really great stuff for nonprofits with Plone. I’d love to have you come talk about it at the Plone Symposium in New Orleans next month.” Before I knew it, I had agreed, and Andrew Burkhalter, Jon Baldivieso and I headed down to the Delta to meet the Plone community in person and to do a workshop on our Plone development practices.

I was nervous. First day of junior high nervous. Not about our presentation — we knew what we were doing with Plone and we’d had plenty of time to prepare. This was a more elemental nervous: “will they like me?” “Will I like them?” What were these Open Source programmers going to be like? Would three self-taught environmental activist/website hackers like us fit in with these world-class programmers? Would we have anything to talk about? Would they like to drink beer?

My nervousness mounted a bit when I realized that our presentation was scheduled for the first afternoon of the conference, and directly opposite Geoff Davis’ high-profile talk about how to make Plone sites really fast. Would anyone come to our talk? Would anyone care? Well, we didn’t have as many people in our room as Geoff did in his. But sitting right in the back row from the first minute to the last were Alan and Alex. As soon as we finished, Alex was the first person to the front of the room, and he said, “Wow, that was probably the best talk I’ve ever seen at a Plone conference.”

Our stomachs unclenched.

Thinking about it a bit over a beer later that night, I realized that this was what effective Open Source community leadership looked like in action. Alan and Alex went out of their way to make us feel welcome, included and appreciated. We noticed, and it felt great. We came back home to Seattle walking on air.

In New Orleans, we’d also met Joel Burton, another core Plone community member, who used to work in the nonprofit sector in Washington, DC before becoming a full-time Plone consultant and trainer. We felt an instant rapport with Joel, and shortly thereafter partnered with Joel and the Plone users at the University of Washington to offer a “Plone Bootcamp” training in Seattle. As nonprofit folks, organizing and promoting an event came pretty naturally to us. It was a smashing success and sold out in two weeks. Joel was impressed.

In June 2006, it was time to start putting together the annual worldwide Plone Conference. The folks in Vienna, Austria who’d hosted it the previous two years were not in a position to host it again, and there was no successor standing in the wings. The Plone Foundation was keen to bring the conference back across the Atlantic. And they realized that the scrappy band of environmentalists from Seattle had shown a bit of a flair for organizing events and for making Plone understandable to non-technical users.

My phone rang again. Several times.

“Jon, we would really like to see ONE/Northwest put together a proposal for hosting the Plone Conference,” the voices of various Plone Foundation board members said. I swallowed hard.

After a couple of conversations with key Plone community members and past conference organizers, we realized that their expectations were both modest and reasonable and the whole thing suddenly seemed feasible. We agreed, and plunged headlong into organizing a global Open Source software community conference for October 2006.

We worked hard on it, the community rallied behind us, and the conference went off without a hitch. 350 Plonistas from around the world descended on Seattle for a full week of trainings, workshops and a coding sprint.

For many attendees (including us!) the highlight of the conference was a keynote address from Eben Moglen, founder of the Software Freedom Law Center and a professor of law at Columbia University. Dr. Moglen is the key legal strategist for the free software movement, and has been a central player in a fifteen-year effort to promote free and open source software and to defend it against legal attacks from powerful and determined corporate adversaries. In his emotional keynote speech (which you can watch online), Dr. Moglen drew powerful connections from the daily work of producing and sharing Open Source software to the generations-long struggle for human freedom and dignity. He placed our work in a far broader context than most of us had previously conceived of, and explicitly linked the values of Open Source with larger values of freedom and social justice. We were thrilled.

We left Plone Conference 2006 tired, but ecstatic. Our post-conference evaluations confirmed what people had been telling us all week: we’d blown away folks’ expectations for what a Plone conference could be. They’d learned a lot. They’d had fun. They felt inspired and energized. We felt like heroes.

But that’s not where the story ends. In fact, that’s where it begins. Suddenly, I was famous. Or rather, an awful lot of people in the Plone community knew who I was, thought I was a good guy, thought that ONE/Northwest was an amazing organization, and felt that we had done a tremendous service to them and to Plone. In addition to that, we were now friends with many of the core Plone developers. In other words, we suddenly found ourselves in possession of “social capital.”

What did that mean? Well, people immediately wanted us to do more, since we had demonstrated some competence. But we also found that we had access and influence. A lot of people were suddenly willing to go far above and beyond the call of duty to answer our questions (and the baseline for duty is pretty high in the Plone community!). The Plone developers actively solicited our opinions about new features and projects. They listened very closely to our thoughts about where Plone needed to go, put a lot of stock in our opinions and were willing to spend time and energy to address our concerns.

Other direct outcomes of our work on Plone Conference 2006 have included:

• Recruiting a key staff person, Veda Williams, from across the country to join our Plone team. “I wouldn’t have had any idea how great ONE/Northwest is if you hadn’t run the conference,” Veda told me after we’d hired her. We’re pretty confident that we’ll have no trouble recruiting more top-tier Plone talent as demand for our services continues to increase.
• Working with Joel Burton to help organize additional Plone Bootcamps — in Portland, OR and a repeat engagement in Seattle, WA.
• A number of minor feature enhancements and bug fixes in the newest release of Plone that will help make our lives as Plone integrators a bit easier.
• Sponsorship from Joel Burton and Plone Bootcamps to send ONE/Northwest staff members to Naples, Italy for Plone Conference 2007, as well as the opportunity to offer a high-profile session presenting Plone 3 the world at Plone Conference 2007 in Naples, Italy.

We’re also hoping to leverage our leadership work in the Plone community into some grant funding to deepen our investment even further in the next couple of years. We know we’ll have the support of key Plone community leaders when the time comes.

The next chapters in the story remain to be written, but we’re very excited about the next few months.

Nonprofits and Open Source, More Broadly

Nonprofits and the geeks who love them can draw some larger lessons about nonprofits and Open Source communities from ONE/Northwest’s experience engaging with the Plone community.

Nonprofits and Open Source communities are both driven by values. Their values are compatible, but not identical.

What’s the same?

Nonprofits are driven by their missions, which are often based in a passionate, values-based vision of how the world can be better than it is. So are Open Source communities. Both tend to value openness, transparency and sharing. That’s really cool. It can lead to great collaborations where nonprofits are willing to invest cash and sweat equity into open-source communities, and give specific, public feedback about the business needs that open-source software needs to meet. For example, Oxfam International has made big investments in the Plone community that have benefitted not only Oxfam, but every user of Plone.

Complimentary strengths

The nonprofit sector has a lot of people in it who are good at building and sustaining thriving organizations that are able to work together across time and space to achieve long-term goals with limited financial and human resources. We tend to be good at planning events, raising money and putting together specific projects that accomplish something tangible while leading toward a larger goal. I’ve found that open-source communities really value these kinds of skills that are commonly found in community organizer and activists.

Conversely, open-source communities have a lot of programmers who are good at finding a way to “just get things done.” The programmers I’ve worked with tend to dislike process and let their results (code) speak for itself. The best open-source communities have a culture of “do-ocracy” (thanks to Kaliya Hamlin for the neologism!), where it’s relatively hard to manifest “stop energy.” Nonprofits can learn a lot from watching these behaviors in practice; we like to think we’re “action-oriented” but we shouldn’t pat ourselves on the back too much. Open-source communities are really agile.

What’s different

Most nonprofits have a specific educational, service or social change mission. The mission of an open source community is usually to build great software where the source code is free for use, inspection and modification. Those missions are not incompatible with each other, but neither are they identical.

Nonprofits often have very explicit (non-partisan) political and policy agendas. Open-source communities tend not to, although their individual members often do! While some nonprofits earn a significant fraction of their income, most nonprofits are not focused on generating economic profits. While many open-source developers are volunteers, many make their living doing technology consulting around the open-source tools they contribute to. Some open-source folks are enthusiastic (even cutthroat!) capitalists. (And to be fair, so are some nonprofit folks!) Bottom line: nonprofits shouldn’t assume that open-source communities share their motivations and ideologies, and vice versa.

Open-source communities are often global in scale, and encompass folks from many different sectors. In running Plone Conference 2006, I worked with people from twenty countries, 35 states, and every sector of the economy including Fortune 500 companies, universities, state and local governments, independent consultants, nonprofit activists and more. It was a far more diverse community socially, economically and geographically than the communities that define many (but surely not all) nonprofits.

On Leadership

In both nonprofit and open source communities, quality leadership matters. A lot. I think that good leadership is probably one of the most important factors in the long-term success of both nonprofit organizations and open-source communities. I’ve been priveleged to work with some extremely talented leaders in both areas.

I think it’s easy for nonprofits to imagine that open-source communities are anarchic or leaderless, simply becaues they don’t have formal hierarchies and organization charts. They’re not. Just because there’s no “Executive Director” or “CEO” of an open-source project doesn’t mean there aren’t strong, dynamic leaders, clear responsibilities and strong decision-making processes. And often, like in nonprofits, the true leadership comes from the edges, and bears little relationship to title or formal position. The leaders are the people who communicate well, listen more, offer positive feedback, and show passion, integrity and authenticity. Social capital flows towards people who display these kinds of behaviors.

I’ve watched leaders in the Plone community go out of their way to make newcomers feel welcome and included; groom new leaders into positions of responsibility; give each other difficult-but-constructive feedback; work towards consensus around big, difficult decisions; build long term strategic relationships with partners; and create long-term institutions to carry on important work even as individuals come and go.

I’ve also watched members of the Plone community make some of the same mistakes that many nonprofits do: squelch creativity with “stop energy”; fall victim to “not invented here” syndrome; forget to treat newbies with respect; forget to celebrate success; fail to consider the longer-term impacts of decisions that seem expedient in the short term; fail to spend enough time listening to key stakeholders; fail to plan for the long-term. We’re human, we make all of the mistakes that people anywhere do.

What Nonprofits Should Learn from Open Source

• Transparent organizational structures that are open to participation can really work.
• Appropriate use of technology tools can bridge time and distance very effectively, but face to face still counts for a lot, so don’t forget to budget time and money for it.
• Spend more time doing and trying, and worry less about perfect decision-making processes. You’re going to make a lot of wrong choices on the way to success, anyway. Failure is not just an option, it’s a requirement!
• Collaborating with your peers, even though you may sometimes compete with them too, is more powerful than going it alone.

What Open Source Communities Can Learn From Nonprofits

• The best nonprofits are very good at telling compelling stories to market themselves and inspire passion and commitment. That’s an important skill, but it doesn’t happen magically. It needs to be cultivated and invested in.
• Invest in leadership skills any way you can. It pays huge rewards.
• Nonprofits are often good at convening people to discuss strategy and make decisions together. There’s a lot of facilitation skills involved in that. Few people are intuitively good at this. The skills are teachable, but you have to commit to learning them.
• The code isn’t documentation.
• Organizing skills, consistently applied over time, are vital to the health of open source communities.

• Overall, the grantees are firmly entrenched in the Web 1.0 world, meaning that grantees use the web largely as a source of information rather than interactivity. 
  
• A small handful of grantees, for instance Witness, the ACLU, Breakthrough, WYNC Public Radio, are using social media in spectacular ways to engage their constituents in conversations.
• Most grantees are not taking advantage of easy-to-use social media tools effectively. The first is the fact that only half have blogs, and that only half of these groups allow comments on their blogs.
• Survey respondents and group discussion participants often felt a “common struggle” in understanding which tools are critically important to their work and were at a loss as to where and how to get help for selecting and using new social media tools.

Alison asks for comments.  Here’s mine, which is admittedly not based on having read the report yet:

I wonder how much of this anxiety is the product of nonprofit sector consultants and pundits hyping Web 2.0 tool after Web 2.0 tool.  

How short was the hype cycle of MySpace?  Of Flickr?  Of YouTube?  Of Facebook?  Of Second Life?  Are all of these important?  Equally?  Should all nonprofits be doing all of these things, plus blogging, social bookmarking, IM, screencasting, user-generated content, etc. etc. etc.?

I think the message that nonprofits are getting from us “yes, and wait until you see what we’re excited about next!”  I’ve seen a lot more enthusiasm for these tools than reflective analysis of their real-world value in organizations with scarce resources.  And I think that’s what’s creating a lot of anxiety.

Or maybe I’m just having a curmudgeonly day.

I’m looking forward to digging into Alison’s report in depth.

(Hat tip to Beth.)

Often called a project manager or product manager or program manager, our Preview Target User however is a special breed of PM. They work closely with every member of their team, acting as a communication hub. They know how to ask the right questions to gather input and feedback. They identify problem areas, figure out when meetings need to happen, who needs to be there, what needs to be discussed, and then they facilitate the discussion to define concrete next actions and ultimately drive their team towards informed decisions.

They go on to offer an intriguing diagnosis of what’s wrong with the current state of the art in personal information management, which underpins Chandler’s different approach.

As the prototypical “Chandler Knowledge Worker” it will be interesting to see how Chandler works.

Kudos to Mitch and the OSAF team for having the wherewithal to stick with a project that has become far more interesting and complex than they ever imagined, I’m sure.

Direct online interaction robs the very important inattentive trust building components to relationships. Twitter, facebook, etc. provide a unique window into watching someone without paying direct attention to them. How many of you log on to do work late at night and “see” in AIM list and Skype list folks that are still online working. Does that over time build your relationship with that person in any way? Does a facebook update on someone going hiking at a place you have hiked before influence your interaction with that person next time you meet even thought you never discuss the hike? Yes.

What if they were taking jazz lessons? What if they twittered they picked up a new Hummer? or bagged a black bear on the first day of the season? You might never bring it up in a work context or direct interaction but you know it is there and your brain files it in the mix. It is inattentive. They were not telling you. They were not looking for a reaction. They were just letting you see if you cared.

One of the key components of network health is social ties. There may be passive network building strategies that should be tested and deployed within a campaign context that help foster building inattentive trust. Such activities might include micro blogging activities and work, shared calendars, regular questions asked about non-campaign related activities and republishing the information back across the network.

The tools are catching up very slowly to all the complex needs we have to understand one another. We need to be aware of the opportunity they present to enable us to build more powerful network capacity even in inattentive and passive ways.

This feels really right to me.