For the software-development-as-urbanism crowd: "When Tokyo was a slum" is an excellent article. It doesn't talk about software, but the process of construction of cities on a piecemeal basis is very illuminating.
When the war ended, Tokyo’s municipal government, bankrupt and in crisis mode, was in no condition to launch a citywide reconstruction effort. So, without ever stating it explicitly, it nevertheless made one thing clear: The citizens would rebuild the city. Government would provide the infrastructure, but beyond that, the residents would be free to build what they needed on the footprint of the city that once was, neighborhood by neighborhood.
[...]
The central part of the city is the historical core of Edo, which became Tokyo in the late 19th century. But the periphery grew largely without planning. Tokyo swallowed up the surrounding villages as it sprawled outward [...].
[...]
Throughout the 20th century, as surrounding villages were absorbed into the expanding city and rural villages became urban neighborhoods, their inhabitants preserved some of their customs and social organization. But the central government never saw the autonomy of these neighborhoods as a threat.
Does Gnome operate somewhat like that, and if so, what can we learn from the process? Is the center (the core desktop) traditionally the "capital", and has it swallowed little villages in the periphery (apps and libraries that became part of the core, or otherwise became tightly integrated with the core)? How much autonomy (let them be) vs. how much central planning (let's tackle horizontal issues)?
How do we remain civil as the city grows, when it is no longer possible to know everyone who lives there in person?
Jane Jacobs, in The Death and Life of Great American Cities, makes a point that one virtue of a great city is that it allows complete strangers to live very close to each other. A great city gets made through explicitly allowing and nourishing diversity: diversity of uses, so you don't have business neighborhoods which go dead at night; diversity of people, so any minority's needs don't go unmet; diversity of age in buildings, so people can afford a cheap shop or apartment if they need one, or a big and new building if they can.
Jacobs also talks about the "self-destruction of diversity":
[...] the tendency for outstandingly sucessful diversity in cities to destroy itself; the tendency for massive single elements in cities (many of which are necessary and otherwise desirable) to cast a deadening influence; the tendency for population instability to counter the growth of diversity; and the tendency for both public and private money either to glut or to starve development and change.
[...]
The purpose of recognizing and understanding [these forces] is to try to combat them or — better yet — convert them into constructive forces. Besides influencing the growth of diversity itself, these forces also sometimes affect the ease or difficulty with which the basic conditions for generating diversity can be introduced. Leaving them out of account, even the best planning for vitality would fall a step back for every two steps forward.
There is a lot of food for thought in all of this. See also, Photoshop is a city for everyone: how Adobe endlessly rebuilds its classic app for a tangible example of a large, old software project, that everyone seems to love and hate. This article also portrays its subject as a world-class city!
The Produce Savant, a wonderful blog about what to do with "unpopular" vegetables. By Sally of the amazing Tools for Working Wood.
↧
Federico Mena-Quintero: Thu 2013/Feb/21
↧