There’s a common expression in software development that recommends “eating your own dogfood” as soon possible. The idea is get to software developers to experience firsthand their work from the users’ perspective earlier in the development cycle. The thinking suggests that this will allow for proper adjustments to be made before a product ships. It’s common sense really; you wouldn’t feed yourself crap, so don’t feed your crap to your users.
Generally you can count on this tactic to help produce less-sucky software, unless what you think is dogfood, really ain’t.
And so for that last couple months, what we at CivicSpace thought was our own dog (that being our CivicSpace software) really wasn’t. It took me some time to come to this realization, but after traveling to Belgium for DrupalCon and FOSDEM, I’ve had a dogfood epiphany.
Political software development at breakneck speeds
During the election, there had been a trajectory for CivicSpace that required a rapid and fault-prone iterative process. In creating one of the first-ever web apps for enabling grassroots communities to organize themselves, CivicSpace (which was known as DeanSpace at the time) had to produce real results quickly, with little time to ponder the future of the software. There was an urgency in the development process that lead to a lot short term decisions being made with little thought to the future of the software.
This was perfectly reasonable given the purpose of the software, but with the election over and the previous incumbent back in office, it’s time for a moment of appraisal: what did our software do right, wrong and how can we build it better to ensure our success next time around?
Where are the leverage points that went unexploited? What about technology scares people so much? What about offline, face-to-face organizing isn’t well-represented in our technology? And what should the process of organizing open-source communities really look like?
It seems to me that the only way to get at the answers to these questions will be to deliberately slow ourselves down, if only for a weekend retreat, and come up with a methodology, a plan and a Big Idea™ that will help grassroots communities better activate and mobilize themselves not only in 2008 but for the next 40 years and beyond.
Suggestions moving forward
The point is, we accomplished some amazing things in this past election cycle. We should be proud of what we accomplished, as I think many people are. But the majority of Americans are still not represented in the White House and there are very plausible things that we can do now and until the next campaign cycle comes around to get ourselves ready.
CivicSpace will play a centrifugal role in open source campaigns from this point forward; there’s no question in my mind about that. What I’m not so sure about is what that instantiation of CivicSpace should look like now, six months from now and still further beyond that. I do, however, have some ideas which I would like to share:
- Define the problem and state your approach to solving it.
As with any development process, we need to first clearly state which itch(es) we’re trying to scratch. And I don’t think there’s a simple or apparent answer to this question yet. In spite of this, there’s been a tendency among us within CivicSpace to blurt out to anyone who’ll listen, “Oh yeah, CivicSpace can do that!” or “Oh man, CivicSpace has to do that!”. But what we’ve failed to do at the same time is adequately define what that is or why we should even care about it!
Once we’ve clarified what it is we’re trying to achieve, pioneering the approaches that will lead us to results will be easier. It will also become easier to spot other compatible efforts with whom cooperation would make sense.
And best of all, being clear about our work amongst ourselves will make us better at talking about our work with other people, which I would argue is an absolutely critical facet of any publicly successful open source effort. One reason that Firefox is so immensely popular is that it’s easy to describe and demonstrate the value of. No more popups!? That’s something people can understand!
- Offer an organic vision and constantly seek feedback.
As with any open source project, we rely on devoted individuals with their own self-interest in mind to actually build our software. What tends to emerge is a community of folks who really want to see a project succeed, and to participate in ways that are meaningful to them. In fact, few if any modern open source projects would succeed without the commitment, energy, enthusiasm and person hours of its users and contributors.
While Zack has done well in getting a community interested and excited about what CivicSpace will someday become, we’ve collectively been scant on the details of how this thing is really going to work or how we think it should be used. Without offering that kind of vision, the real value of CivicSpace is buried within the hype.
If we can put into reasonable terms (or stories, as I like to say) what it is we’re trying to help real people accomplish on their own and then get buy-in from our community on those stories, we’ll all be much better off in how we structure and manage ourselves, our contributors and the community around CivicSpace.
- Saying no by default is an essential skill in all creative endeavors.
I’m admittedly borrowing directly from the wisdom of 37 Signals, but this is so universal, that it’s worth mentioning here.
Looking at how CivicSpace Labs folks talk about our product, we believe that it can do anything and be put to nearly any use — both because of the genius in the way Drupal was built but also because we subconsciously equate enthusiasm with effort. Therefore the more enthusiasm there is, the easer it will be to make.
But anyone in software development can tell you, as Neil tells me so often, that nothing is trivial. It takes many many hours just to add a single feature, and since whatever we create ultimately needs to work well for an incredibly wide audience, we can’t simply add Bob or Mary’s favorite pet feature. Not without putting off some other more widely useful part of the tool or without pushing back release dates, which we’ve already become notoriously bad at sticking to.
Therefore it’s incredibly important that we begin to manage user expectations by saying no by habit; we should always sleep on an idea before dropping some more pressing issue in favor of working on it. If we get better at doing this, the next dictum should happen naturally.
- Underpromise and overdeliver every release.
In practice far too few project managers get the religion on this one. Oftentimes their enthusiasm leads to promising the world and delivering something far less satisfying. But here’s the real threat with this: disappointment, especially repeated disappointment, kills your community, your reputation and erodes a team’s morale.
It takes practice and experience to build up a sensitivity to all the things a release is bound by, such as limited time, limited personnel, and the need for testing (all kinds).
The interesting thing about this is that it really doesn’t what your software does, as long as it does it well, consistently and in a way that meets users’ needs and is released in a timely manner.
- CivicSpace is creating a Drupal distribution.
Part of achieving the previous rule is to make our promises more realistic. We can do this if we push the fact that CivicSpace is creating a Drupal distribution. This means that we are bound by rules, expectations and caveats imposed upon us by a secondary development ecosystem, in which we are an equal member of a community.
Drupal and its community have its own interests in mind; if CivicSpace goes away, Drupal will not. We don’t have any special privileges and we can’t force things to get done faster simply because we need something sooner than everyone else. We have to pull our own weight and earn develop our reputation within the community, and there’s no shortcut. We need to provide code, patches, mockups and a presence just like everyone else.
The good news is, we’re currently working on this.
- CivicSpace is a process, not a product.
I’m going out on a limb here, since we haven’t achieved consensus on this point within CivicSpace yet, but I believe that what we’re creating is not a product, no matter how much we’ve talked about “CivicSpace” as though it is one. This is simply not accurate given what’s happened and happening within Drupal, Spread Firefox and even the CivicSpace community.
What we’re doing is leveraging long-established open source traditions to help people organize themselves better to do things other than build software. We’re focused on progressive causes, but because we’re working in the open, we can’t (and don’t want to) control who uses our software product.
So the only way for CivicSpace to really serve the progressive community is to offer them something that progressives need, can use, and will give them an advantage over other adversarial initiatives. What CivicSpace can offer is a process (based on our experiences) for being more inclusive, open and grassroots-powered. It just so happens that the software toolset that will encourage and enable other people to use this process is a by-product of us using the process!
Factory Joe 
Saying “No” by default reminded me of wise advice I once received from a Big Six IT consulting partner. He said, “Write the word no on the palm of your hand. When the client asks if you can make a change, look down at your hand, and gently reply ‘No’. Then be ready to negotiate.”
I would also add, if a fix or feature takes two minutes to do, never, NEVER let the client watch you do it.