Whups: Correction (and not, and question, and…) about Open Source and Philly

Last month, right before signing off for the Chaos Fest that is the holidays around here, I posted an article about two of the platforms featured on this site, and how they had worked together on a project in a way that I thought embodied a good example of how more firms should be doing this.  My friend Frank Hebbert, who is the Director of Civic Works at OpenPlans, however, found what I had written to be off the mark importantly enough to write an articulate and well reasoned response... on the Friday afternoon before Christmas.  When someone cares enough about getting the fact straight, when you’ve said something nice about them, and it’s end of the year zooey time… you have to admire that and take it seriously.

You can read Frank’s response here.  Basically, his point is that I over-stated the importance of the fact that the code used for the two apps in the Philly bikeshare project were open source — not only did he correct me that Textizen is not open source anymore (it was in its Code for America development days, but not anymore), but he asserted that it was the availability of open data, not the code itself, that made the collaboration work, as well as the “maturity” (his word) of the firms themselves.  And Michelle Lee, the CEO and co-founder of Textizen, agreed with his assessment.

So, factually, I put two and two together and got six.  And I want to publically acknowledge that.  But there’s a deeper point, and I think a crucial point, that I was trying to get at in that first post — perhaps less to do with open source code, and more to do with an open source worldview.  And I think that’s still crucial to unpack and talk about.

I wrote the following as a response to Frank the day after his post hit, but I decided to sit on it until after the holidays so that we could continue the conversation with more than the three brain cells I can summon on December 23-27.  My hope is that we can have a dialogue about these issues within this industry — on this site, on Frank’s Open Source Planning blog, wherever.  It’s a crucial question that we have to figure out if online public engagement is actually going to meet its potential to empower communities to make better decisions.

Frank –
I’m thrilled that you thought enough about the issue and about my attempts to understand it to respond – especially since you apparently did so on a late
Friday during the chaos season of the year! Sorry I took so long to respond – I wanted to make sure that I was thinking it through carefully, and also
working around a little chaos, too.

I think I understand your point, and I didn’t know that Textizen had gone off open source, so that was news to me. I knew when I was writing that piece that I was on a little bit of thin ice, since I certainly was looking at the project from the outside (pretty far outside, at that), and certainly couldn’t personally see how the interface between the two platforms worked.

I’m going to try to articulate why I went out on that thin ice a little better, because my motivation for doing that was an issue that I think is starting to
become a problem for online public engagement, from what I see playing out. And then I’m going to ask a question – of you particularly, but also of everyone
else who wants to be part of the discussion.
The thing that struck me about the Philly BikeShare project was that this was the first time that I had seen two online public engagement platforms directly collaborate – make something that worked seamlessly, incorporating two separate platforms with two separate companies. Maybe that’s
happened somewhere else and I missed it. But what struck me what how…well, impossible that had been when I had tried something like that a couple
of years ago.
In 2011-2012, I had a consulting contract to manage public engagement for one of the Sustainable Cities challenge grants. The client wanted to do a pretty
high-visibility online public engagement platform, and they had one provider that they particularly wanted to work with. To do everything that they wanted to do, however, we needed more than that platform was designed to do. So as a result, I brought in another platform to provide those additional services, and I told both companies that we needed an online presence that looked and functioned like one site. The first site was a proprietary application, while the second was more module-based, and built on an open source platform.
After much discussion, we learned that the first platform could make hardly any changes in the direction of creating a seamless platform. The best they could do was to skin the site to match the project’s design characteristics (the second platform then designed its interface to mimic the first one). But that’s as far as the integration went. We had no way to incorporate information from one platform into another. We couldn’t port an issue raised in a survey on the open source site to the other’s commenting platform, we had to manually post the same background information on both sites (and attempt to keep them both updated so that you didn’t get one version on this side and one on the other). We were basically running two separate online public engagement platforms and trying to physically manage them into relation with each other. It was so labor-intensive that it never worked like it should have.
When I saw that OpenPlans and Textizen had managed this kind of interface (again, without seeing the actual code – and I am very admittedly not a coder, although I am trying to learn), I inferred that the fact that the code of your two products was *not*protected by a thick layer of secrecy and lawyers may have meant that you were able to make adjustments to get them to work together better than if you had just run them separately. Sounds like I put two and two together and got six. Which, any time you’re commenting on someone else’s work, you might very well do.
But here’s why I took that risk – and in stating this, I am going to quibble a leeeetle with one of your statements toward the end of your response:

Right now, the world of online public engagement tools is in the later stages of this sort of Cambrian explosion of apps, platforms, etc.  Most of them only do one or two things. They might do them well or not so well. But they only do one or two things. The more mature ones have learned to admit their limitations and own their niche.

I think a lot about online public engagement because I’ve done the on-the-ground type for so many years, and even when you do it excellently, I know
what the limitations are. And one of the things that I have learned over many years is that planners and other public officials tend to think about public engagement far, far too simplistically. You did a survey? You asked for a bunch of ideas and let people vote for them? You held an open house at the community center? Good for you!!!! You’re done!!!! Go make your plan in your back work room… and maybe trot it out for all those folks to see when you’re basically done. They had their “input,” that’s good enough.

And then we wonder why we have so many angry people at those final public meetings. Or why they wonder whether that whole survey-filling-out, voting-on-ideas is worth the time it takes to bother. And why, then, it’s so very hard to get them to do it at all.
What I desperately want to see, in online public engagement and in offline public engagement, is a shift from doing a public engagement activity once in a while, when you have to, to a relationship-building process that pulls people into the decisions of their community all the way through. One that meaningfully involves the regular people who know a community in a way that the professionals can’t (your accident mapping project being a great example of that), and makes them part of the whole process, so that they have ownership of the whole process – and as a result, so that the plan that comes out of it has people who will advocate for it, work for it, play an active role in helping make it happen. Throwing the occasional survey or ideation platform at them just doesn’t get that job done, any more than the occasional open house or “Vision Session” does.
I know what that kind of deeply engaged process looks like in person, and I have seen for myself how incredibly powerful and effective it is. I don’t yet fully know how to do it on line. But I strongly suspect, given the landscape of firm
s and applications that have developed, that what we’re going to need is the ability to do exactly what OpenPlans and Textizen did – combine and
recombine the larger tool kit of all the online engagement strategies to best fit a specific situation, community, plan, point in that relationship-building process. And be able to make sense of the information gained without spreadsheet

Maybe what I should have referenced wasn’t open code per se – as you rightly asserted, most local government departments probably aren’t well-served
to use what little capacity they have to manhandle a fork of a Github repository. And quick-start, SaaS – type apps have certainly made online participation possible in a way that having to build your own website from scratch never would have.

But what I think is critical – and broadly lacking in the field– is what you might call the spirit of the open source approach – the belief that my app or platform won’t just operate alone, but that it needs to be able to be part of something bigger, capable of combining, integrating, with others. Some non-open source providers, such as Delib, already have “modules” that can be readily combined based on the needs of a project, but instead of being limited to using two or three of these apps in concert, communities need to be able to combine a whole range of platforms – and do it without having to spend time and money they don’t have on awkward code patches or manual data manipulation.

I think that’s an important next wave of this business, and I suspect that it’s as
much a business and psychology problem as a technical challenge. The mega-impact of open code, open data, open anything is, of course that it turns the old business models of proprietary, restricted, protected, on its head.

So perhaps what I was really writing about was something along the lines of open code spirit, rather than open code in the technical sense that you all
know so much better than I do. That’s what I felt was the important lesson, the much-needed-example, that OpenPlans and Textizen laid out in the Philly
Bikeshare story. Regardless of how it was coded, you two sought to work together, to integrate as much as possible for the good of the project and the community that it serves.

My question to you, and to everyone else who is reading this, is, how do
we increase the power, the impact and the flexibility of online public engagement? Is there a way to enable all these platforms to work together more effectively? If it’s not an open code matter (which I understand isn’t the answer), then what needs to be done?

How do we get to the point where I can set up a process involving multiple online engagement platforms simultaneously or over time, moving the information gained in other activities from one to the next seamlessly, leading people from an activity on one platform to the next step on the other, integrating the results across platforms to help decision makers get a clear, not fractured, picture of what the community is trying to tell them?

That’s what I really want to know.

Frank, Michelle, and the rest of you at OpenPlans and Textizen: even though I got it wrong, I still say, good job, guys.  And thanks for continuing my own education.