We in CUNY like to think we’re big. And we are: a multicampus university with nearly a quarter of a million degree students — the largest urban university system in the world. So when I was recently asked to review the program document for Project Bamboo, “a multi-institutional, interdisciplinary, and inter-organizational effort” involving over 110 institutions, I realized I had a chance to see what thoughtful people were saying about a project still larger than the CUNY Academic Commons, and still, like ours, very much in the beginning stages.

I’m impressed by the thought and work that has gone into this draft, and I think there’s a great deal to learn from it, particularlly from the Scope of Work section. But I also see a general flaw that I hope don’t afflict the Commons: Bamboo seems too technology-driven, too interested in how, taking the what and the why as givens or as questions largely answered by the status quo.

The reason Bamboo seems so tool-focused and technology-driven comes, strangely enough, from the realization that it shouldn’t be: the articulation of the Program (2.3) is framed just that way: “Because Bamboo is much more than technology, the program includes three distinct areas of focus and leadership: Bamboo Explore, Bamboo Plan, and Bamboo Build.” These areas are oddly incommensurate. Bamboo Explore (2.3.1), because it is about needs assessment, focuses on givens, presumes community.  Very little is said about it beyond making it the realm of requirement gathering. Bamboo Build (2.3.3), at the other end of the time spectrum in this oddly linear plan, is about tools we can come up with only after Bamboo Plan  (2.3.2) has done the prioritizing and planning. So of course the most is said about Bamboo Plan, the mapping activity predicated on satisfying existing needs by means of tools yet to be developed, even determined.

I suppose somewhere in the discussions someone has said that this is about community-building as well as tool-building, and that these are transformative as well as recursive activities, but things are not laid out (and certainly not numbered) that way. Instead, we begin where we are, by asking what needs we have now that things we can build will address. This has a kind of logic to it, but I think the plan reifies what’s wrong with most technological development: it doesn’t acknowledge how means transform ends (admittedly a hard thing to do at the outset). And so it is essentially about using tomorrow’s tools to address yesterday’s needs.

The counterintuitive power given the status quo in what is supposed to be a great leap forward does have much to do with where and how you start. I’m willing to stake a lot on the idea that, even and especially in big projects, it actually makes sense to build the plane and fly it at the same time. That way you’re in transit when you try to figure out where you are and what that may mean about what you need.