想法的由来
Larry Wall 的 Patch 程序在那个年代的网络下对于黑客们非常重要,
Patch 的出现使得人们能够通过增量更新软件, 否则更新时下载全量的代码将非常缓慢
而 Git 分布式的设计也使得大量程序员共同维护代码成为了可能
现在 GitHub 俨然是开源世界的中心, 大量的开源软件托管在 GitHub 上
同时 GitHub 社交功能渐渐成了程序员频繁使用的功能
除此之外, 我们有大量的邮件列表, 论坛, 问答社区, 聊天室, 提供线上的沟通
线下比如上海能看到越来越多的活动, 邀请聚会, 交流技术, 认识新朋友等等
也有着更多人进入到程序员社区当中, 并且大家展开交流
考虑到网络未来成为人们展开大量活动的场所, 技术人员数量将会激增
我比较喜欢用城市来比喻网络, 人们在其中添砖加瓦
庞大的社区意味着信息流动可能变得低效, 这在网络发达的年代显得不好
另一方面, 随着我最近参加社区聚会的增多, 我对参与社区的效果有些疑虑
最早阅读"怎样成为一名黑客"的文档时, 里边强调要多参与 Linux 社区的活动
因为在活动当中有人教授关于 Linux 操作的知识, 这对于理解程序来说非常重要
问题是现在媒介已经发生了变化, 在线社区储备了大量资源, 很少需要面对面才能传授
而且参与社区人数增加, 参与也不是意味着都能获取切题的高质量的知识
考虑到线上的社区交流的频率远远大于线下, 我认为线下社区仅仅是作为线上的辅助
比如 Teambition 开展 Session 做分享和交流, 主要还是企业文化方面的考虑
作为纯粹的技术人, 我希望在活动中了解新技术增进交流, 单纯在 Session 并不是总有收获
当然我不是在讨论 Session 的问题, 而是大量的程序员, 信息怎样能更好地传播?
而且线上的技术媒体在这方面带来的效果显然更好, 同样问答社区也非常地精准
树状的模型
经常逛社区的大家都知道, 现在有大语言的论坛, 其次还有各种平台的论坛
也许我们可以设计一份开源导航先把这些社区索引起来~
但是我们先试着看看一个更简单的列表, 把我们关心的事情展示出来:
- 技术前沿
- 关于技术前景预测和评论
- 学习新技术的成本
- 解决对应问题的模块
- 开发当中遇到的难题的解决方案
从上到下, 我认为内容针对性越强, 对应的人群越窄, 传播越有效但量更少
可以想象这些内容集合在一起, 像是一棵分形的树, 不同程度地吸引关注度
而每个人的精力只能同时停在树上一些位置而已, 关注越多, 成本越高
同时, 新的内容是在这棵树不同的位置生产出来的, 也有可能是树的外边
这些信息一起, 对所有社区中的人带来影响, 决定了社区以后演化的方向
而这些信息需要传播给各个位置的人, 存在不小的传播的成本
而且作为程序员, 我们更希望同样的问题不要总是不小心去重复解决
而是更多的人能够在一起协作, 其中每一个人所做的能合理得在社区当中传播
内容的细分跟回合
信息增多之后, 对需求进行细分, 针对每一种提出合理的方案, 大概是一种趋势
比如说针对每种编程语言的社区开始独立出现, 并出现微博和 QQ 群等不同的方案
另外人们获取信息的成本不应该很大, 否则就是巨大的门槛
我也想不出什么新的东西, 只是认为这些值得细化, 而且相互间更好地配合
猜想未来几百几千人碰到一起, 在网上进行协作, 也不是什么稀罕的事情..
常见的几种细分的渠道:
- 微博
- 论坛
- 聊天
- 问答
- 新闻
- 博客
- Wiki
- 聚会
- 会议
列表越往下收听的成本越高, 也意味着可能对质量控制更高
有那么多种方式, 是因为真的需要做各种不同的沟通来应对多样的问题
这些目标体现在各种大大小小的需求当中, 而单一的工具显然很难全部满足
而且这样做也尽量避免掉在工具层面形成的障碍
另外我想到了一些这些渠道之间相互搭配来增强的方式:
- 更新新闻, 帖子, 博客, 活动, 将其转发到微博, 这是目前经常做的
- 博客, Wiki, 活动的页面, 增加 Disqus, 形成一个简化的论坛
- 问答当中频繁的交互切换到聊天, 这一点 StackOverflow 做了
- 通过聚会相互熟悉成为联系人, 进而在论坛或者聊天中增加互动
- 论坛的形式在技术上更实时, 达到聊天的效果, 比如 GitHub, Gitter 之类
- 将论坛的内容整理到新闻, 比如 InfoQ 会把 Hacker News 的评论整理成新闻
- 聊天内容转存到 Wiki.. 这一点似乎很少
- 聊天中的内容变成线下的聚会.. 这在小团体当中似乎很常见
- 博客, 新闻当中的内容整理到活动当中分享, 这也挺多见
这样做的目标是:
- 技术人之间的协作, 更好地解决掉技术问题
- 信息应该通畅地传递, 大家消耗的成本不应该很高
对应的两个极端的情况:
- 各自为战, 不做交流, 导致花时间重复解决问题或者耽搁了问题
- 某些渠道过窄, 以至于太多消息拥挤在另外一些渠道, 形成噪音
流动的方向
有了那么多渠道之后, 再考虑下产生的内容是以怎样的方式流动
互联网带来了扁平的关系的结构, 带了很多个可能, 也有着紊乱的可能
一个可能是新手发出太多声音, 信息泛滥, 重要的声音反而被淹没
即便某种程度上我们很自由在交流.. 但恐怕很多时候并不是高效的.
重新排列一遍上边的几种需求, 可以想到对应的内容:
- 技术前沿
- 关于技术前景预测和评论
- 解决对应问题的模块
- 开发当中遇到的难题的解决方案
- 学习新技术的成本
从上到下, 从大牛到新手形成一个梯度, 并且后边的人会往前边提升
从追随他人的脚步, 到为他人探路甚至开路, 这中间需要太多的努力
但我有点觉得突出这个梯度, 形成内容流动的方向, 对技术社区会好一些
我并不是说技术自由地交流, 而是这样的流动的方向
- 最开始是编程思想, 工具设计的理念
- 然后是具体工具实现和使用
- 其次是具体到各种问题提供怎样的解决方案
- 终点是编写业务逻辑的具体代码
而社区交流主要就是将大量经验和努力汇总的知识从起始点往终点流动
不过现实的压力倒是正好反过来, 越接近终点, 人们越想快点干掉..
这些压力也形成了对编程思想的反作用, 架构需要更多魅力才能吸引业务代码
因此我挺希望社区的力量能孕育出好的编程思想来和架构来
