Yesterday, I had lunch with an old friend whose new company is working on a project to templatize community commons—spaces in geographically bounded neighborhoods where local residents can meet each other and form the kinds of ties that make living in a community enjoyable.
“Commons” here is not used in the usual, technical sense of a shared, non-excludable resource. As I understand it, these community commons are intended as physical locations with programming intended to stimulate the formation of commons in the form of networks of ties formed between the members of each geographic community. The thesis is that developing these ties makes the communities enjoyable to live and work in, brings inflows of people and investment, and increases asset values. These community commons are not themselves true commons, but tools or systems designed to create a commons. Maybe we should call them Kommons instead.
Several observations, all at the level of anecdotally supported opinion:
Urban communities should have extensive and overlapping networks of weak ties established in a wide range of domains, not dense networks composed mostly of very strong ties established in a small number of domains. The desired result is the possibility for individual freedom within the context of a background sense of connectedness (think Jane Jacobs) instead of a stifling sense of overdetermination (think gemeinschaft). A Kommons should aim to create diverse and multityped weak ties instead of concentrated and monotyped strong ties.
For a Kommons to be effective at stimulating extensive weak-tie formation, it must respond to the composition and needs of its community. This implies that the Kommons itself should be as susceptible to change as possible, for as long as possible. One way to achieve this is by investing as little as possible initially in the physical plant (think evolutionary maintenance instead of one-and-done construction) and designing the programming to expire and be re-instantiated at regular intervals (think apoptosis and evanescence instead of planned persistence).
Because the concrete form a Kommons should take is so highly context-dependent, the Kommons template is unlikely to be effective at the programming level or even the physical design level. Additionally, insights about what “works” in programming a successful Kommons are likely to be determined by the particularities of where the research was done. Programming details are better left to implementors with both skin in the game and an ear to the ground. Templatization for Kommons is likely to take less familiar forms, such as low-cost corporate structures and preferential access to funding streams (on which see more below). To some extent, this requires thinking about the project of templatizing Kommons without ego. The physical and programming design of a Kommons template should be as ego-less as possible on the part of the template designer.
The main long-term failure mode for a successful Kommons is when its success tears apart the community it has helped to build. When a Kommons is successful, the community it is embedded becomes increasingly attractive and asset values in the community rise (“gentrification” is a good-enough term for the problem). If privately realizable asset values rise above asset owners’ imputed value from belonging to the community, it makes sense for these asset owners to sell out—the community begins to turn over as those who sell leave and are replaced by demographically different new members. A community can survive slow, low-level turnover of members, but not for long, and not if the turnover rate continually increases. Once asset values begin to rise, they tend to continue rising—turnover tends to increase once it begins, only stopping when the bubble bursts. A Kommons may succeed and yet fail when it is located in a community which has no ability to resist such private manoeuvering once this incentive arises.
The solution to the long-term problem of a successful Kommons is to prevent turnover by design: Solving the problem in advance of creating it by limiting the ability of a community’s members to privately benefit from a Kommons’s success by leaving the community. One way to do this is for the Kommons template to include purchases of real estate in the community and the formation of a trust to hold these assets in perpetuity. There are many ways to structure how the assets of such a perpetual trust are managed (to optimize for revenues or operation size or what have you)—these design decisions are contextual.
What’s important about the perpetual trust attached to a Kommons is (a) how extensive its portfolio of real estate assets is at establishment, and (b) how the portfolio should grow as the Kommons develops. For (a), the portfolio must represent a sufficiently large fraction of the community’s total real estate by the time asset prices begin to increase that residual private manoeuvering is unlikely to affect it. This is not merely a question of relative size but also one of structure. If the trust’s holdings are concentrated, they are likely to be easier to acquire and manage but less effective than if they are distributed and highly fragmented. Partial ownership of buildings or blocks can significantly impede consolidation and redevelopment (Tokyo is a case in point). For (b), completing the entire asset portfolio purchase before the inception of the Kommons is both impractical and unwise, primarily due to expense and uncertainty. Instead, the viable mode is staged purchases, possibly by exercising options purchased at the outset and tied to Kommons development milestones.
Setting up a Kommons right (in the sense of protecting the improved community from damaging private profiteering in the event the Kommons is successful) will inevitably be expensive. The upfront expense of a well set-up Kommons is primarily in real estate. This means that investments in Kommons are backed primarily by real estate (safe as houses) instead of programming (high variance). Kommons are thus an opportunity for creating a comparatively low-risk investment channel for capital that wants to invest in community development—an approach that bears many similarities to how real estate developers have begun to use short leases to artists (for instance) as a way to systematically increase the underlying value of their portfolios.
A Kommons is not a commons but a system for creating a commons (an extensive local network of weak ties). The most important implication, in my opinion, is that Kommons will fail when they succeed if they are not designed to prevent community members from benefiting privately by leaving the community. Designing long-term successful Kommons requires both consideration and preparation for meta-level implications of success.