开源城市——share，incompleted、cooperation
前言
立于信息时代盛世之隅，物质世界的壁垒在代码化中削弱；技术、观念和思想也尽情绽放在这无边际、非线性的芯片舞台上，个体地位（individual agent）凸显、群体智慧（swarm intelligence）萌生，我们的“美丽新世界”宛若达到了从未有过的开放与包容，站在巨人的肩膀上采苹果也仿佛不再是梦。数据给予技术支持的同时也提供了无限的可能性，而开源城市这个观念也是应时而出，正如智慧城市（smart cities）这一概念一样，受益于大数据时代的开源城市将更加强调分享share、透明transparent以及公民的自主权individual initiative。当然，虽然操作上仍有难点，但作为数据城市的实践，开源城市或社区仍然有它闪耀的价值。
1. 什么是开源
提到开源，不得不提程序猿的福音—开源社区Github和大热的拼车系统Uber。Github本身是由有共同爱好的组成，用开源软件公布代码的网络社区。互联网的出现本身打破的地域等物理空间的隔阂，而开源社区则更是提供了不同开发者之间沟通交流的平台。而自由的空间，也更加利于多个参与者共同开发开源软件，使得开源社区时刻都有新鲜血液流淌，而积累下的代码又能造福后人，使得大家不用再做重复的事，有效促进科学技术的进步。某种意义上讲Github也是一个如同facebook一样存在的大型网络状社区，而网络状结构对于信息交流、社会结构扁平化都是有利的。
同时，开源社区也具备更强的适应性，一方面开源造成资源共享，能节省大量能源成本，另一方面，源源不断的贡献者也可以维持开源社区的持续繁荣。当然，开源社区也有一些不足，比如由于开源的利他性和自愿性，社区对于开发者非常亲和，但并不对使用者亲和（not user-friendly），这也造成了使用者界面（user interface）这一环节的缺失。同时开源社区虽然大部分是免费的，但也会产生很多隐性的维护成本，也不同忽视。这些缺点在开源城市这一概念里也需要提高警惕。
另一个例子则是Uber，这里开源主要指其模式。实际上，单从经济上看Uber是一种共享经济（sharing economy）概念，与淘宝类似，Uber提供了一个有序的交易平台（marketplace platform）。但从模式来看，Uber提供了很多开源的可能性。比如拼车系统，一种分享模式，人们任意随机组合共享资源，这也是开源的一种理念。另外，这样类似的平台都有着几个共通点：
分派Dispatch
回馈 feedback
交易 billing
顾客服务 customer service
而这些都是开源可以更好解决的，开源系统的数据回馈链（a feedback loop）能很好提供及时的反馈和修改。另外，不同于封闭开发者——开发者需要时刻关注自己的程序进展，开源使得更多的参与者可以自由进来，而起始开发者不必卷入到后续维护之中。
2.开源城市背景
提到开源城市之前，需要先提到一些近现代建筑理论。一则是文丘里的“模糊性”。认为这世上没有觉得的对立，很多都是模糊的介质，建筑是复杂而矛盾的，需要容忍与通融，需要允许即兴活动。另一则是柯林罗的拼贴城市理论，主张更自然的肌理，讲求共存，讲求多元复合。
归根结底，这都是战后现代主义(post-war modernism)弊端凸显后的反思。柯布西耶式的乌托邦实验与指令，技术上的突飞猛进却迎来了城市文脉与记忆的大量破坏。实际上，乌托邦永远都没有离开人们的潜意识。理想主义色彩、普通道德、公共共有（commons）、公平主义某种意义上都是乌托邦的温床。一模一样、生产线式的高层楼房，达到了乌托邦式的“社会公平”却换来了有机肌理的消融和城市文化的清贫，时代精神的沉迷与超级理性的追求却换来了精神世界的极度匮乏和文化的割舍，对于现代交通系统的针对和计算机技术的滥用导致了社会连续性与城市结构的撕裂。因为这些亲眼可见的“文脉的困境”，后现代的建筑师和规划师对于现代主义的弊端自然免不了批判与反思。但实际上，只是批判很容易陷入另一种乌托邦：把“无为而为”当办法。对于有机系统的过度沉迷，对于历史文脉的过度保护，对于古典城市肌理的追捧都有可能产生消极建设、破坏城市原真性、割裂未来等不利结果。而放任不管，任城市自然更替过程中免不了陷入一些由供求关系产生的不利后果，譬如城市乡绅化，中心城市拥堵甚至是整个城市的大萧条。
所以城市共存，当然不应该是一种口号，而是需要有应对城市发展的策略与手段。同时，对于城市存在的矛盾也不应该是对立的眼光，而是求同存异的目光：科学集权与垄断和公民参与的矛盾，美学与政治、功能的矛盾，拆迁建设与原始城区衰败的矛盾等等。
其实，西方理论普遍认为城市的状态为未完成（incompleted），一方面虽然大规模城市建设减少，但城市可以不断更新，从状态来讲是未完成的。另一方面，公共的空间永远是不足的（insufficient），在城市更新过程中，往往会存在优化结构，增加更多口袋公园和改造旧区等策略解决公共空间不足问题。再者，城市发展是四维的，除开空间的平面蔓延，垂直蔓延，还有时间的控制与张力，有随着时间的不同全新理念拼贴，这些都会加强城市的未完成性。说到这点，其实开源城市理念与智慧城市不同的一点是，后者的封闭性终会导致技术壁垒产生，城市网络智慧连接与更新受阻，数据技术发展终会逐渐止步不前。而相比之下，开源城市的共享与自下而上的参与，会让城市更新与相互影响更加迅速。
3.开源城市
可以说，开源城市也是大数据时代的产物，一个很好的例子：大数据时代政府对于数据的透明化处理也是一种开源，为后续的开发者、设计者、规划者甚至普通公民等都提供了更好的参与机会。而这里必须要提及大数据城市理论几个核心的要点：自下而上（bottom-up）和主体建模（agent-based）。这也意味着开源城市具备数据时代的优点：
共享性，打破科学垄断
打破距离限制，远程协作，方便更改与团队合作
生产民主化，公民参与。将原有的垂直社会结构扁平化，强调个人自主性。
更多启发式空间，因为群体智慧的影响，跨专业的合作将会增加更多结构新组合
如果把城市物质空间作为硬件，那么人的行为则可看作软件。封闭系统里人按部就班的生活，受系统控制与影响深。当系统做的很好，如苹果系统，那么人们会产生依赖性和排他性，并且节奏很容易被开发者所带。当系统做的不好，如某些教派，那么很容易被教义洗脑，做出破坏性结果。但开放系统则不同，人们共通知识，消除大量信息壁垒，共同合作，积极参与到城市发展交流里来，一方面城市发展可以更贴近基础生活，另一方面，互相沟通理解，也利于包容新思想的诞生。
Wikihouse是开源硬件的一个例子。比起只有富人能找人设计房子，WikiHouse 更希望将建筑设计与开源相结合起来，让任何人都能设计、下载和制造房屋的建筑构件，并能快速地建造起简易房屋。特别是贫民区、灾区，也能快速建造出既实用又美丽的建筑。
Bartlett学院也做过一个有趣的拼贴尝试，一个主题为incomplete city的workshop。由所有人参与设计城市原件，再大量复制，由不同拼贴方式拼贴成不同主题的城市，再将不同主题的城市合作一起建立更大的城市。这一个实验，最核心的有几点：
自下而上的开源性：城市零件如同“代码”一样由学生创造与“上载”
节省重复的工作时间：复制代码可以直接用来使用，不需要再创造别人做过的东西
更新与再组织：不同代码可以通过不同组织方式生产不同的“软件”，即不同的城市结构。
连接与分享：不同城市之间理念共存，通过交通平台等“代码”进行组装与拼接，达到数据共享和城市融合。
未完成：新的一些思想以后续方式补充进原有城市结构里，进行再创造
其实，开源城市这一理念的内容，比如开放、分享等都是很早就被提及，比如一个社区的旧工具互换网站（比如谁家有闲置工具，谁家需要工具，通过线上社区即可快速完成，达成资源共享），比如共乘系统（将要到达一个相近地方的人叫同一辆车，在数据时代，将由数据系统控制的无人车代替）。只是由于大数据的出现，开源城市有了更多的技术支持。而连接性往往是城市发展的根基，高速交流反馈的数据对于城市的发展有非常多的积极意义。开源，现在看似乌托邦的共享主义，在不远的将来，互联网大幅度扁平化的时代，或许也会成为现实呢？当然，笔者其实更偏向会诞生更多的中小型开源社区，渗透到生活的方方面面，改善生活促进科技，比如医学发展，比如社会福利，比如社区发展等等。
Open-source neighbourhood
Open-Source Cyborg Hand is MakingProsthetics More Accessible than Ever
参考文献：
1. http://www.domusweb.it/en/op-ed/open-source-urbanism/ , Acessado em 25 de setembro de 2012 às 14:30 h. Open
2. Sassen, S., 2011. Open source urbanism. The new city reader: a newspaper of public space, 15(1).
3. Bradley, K., 2015. Open-source urbanism: Creating, multiplying and managing urban commons. Footprint, 9(1), pp.91-107.
4. Jiménez, A.C., 2014. The right to infrastructure: a prototype for open source urbanism. Environment and Planning D: Society and Space, 32(2), pp.342-362.
5. https://wikihouse.cc/