大公司效率低最根本的原因是什么?

首先:小公司为什么会变大?
然后:在变大的过程中,发生了什么?
继续:为何大公司效率会低?
最后:为何大公司,快不起来了?

一、小公司为什么会变大?

当然,通常只有业务发展良好的公司,才会变大。所以,最直接的原因是:活干不完了,必须加人。

加了人之后,自然要派活。既然是派活,自然要有所分工。举个简单的例子:如果公司只有一个程序员,那自然所有的活都是他干。加了几个人后,自然可以分前端、后端、DBA、测试、运维…种种角色。

不同的工种,自然需要协作。开会、文档、上下级关系,自然也要逐步建立起来。这些,都可以认为是「合理的开销」。

二、在变大的过程中,发生了什么?

1. 辅助性部门开始出现:人多了以后,需要专职的HR;占地广了以后,需要专门的打扫、清洁人员;统一的后勤保障,也变成刚性需求;
2. 协调性部门开始出现:PMO这样的办公室,用于协调多个项目;会议越来越多,需要有专门的协调会议室的部门;多个部门之间的矛盾,需要有一个更高级的联席会议进行协调;做事要有规范,专门制定流程规范的部门开始出现;
3. 监察性部门开始出现:人越来越多,难免会混入坏人,所以要有「道德自律委员会」;事越来越多,难免会出纰漏,所以要有「质量保障委员会」;外部交易越来越多,难免会有风险,所以要有「合同风险审查委员会」;
4. 竞争性部门开始出现:在某种管理思路的影响下,开始设立多个目标类似的部门,以期通过内部竞争,促进效率提升;

这些部门,都没有必要吗?当然不是,老板又不是傻子!

三、为何大公司,效率会低?

首先我们需要理解,怎么算效率高?怎么算效率低?同样一件事情,如果很小,很简单,往往小公司会做得更快,甚至更好;而大公司,则会做得更慢,甚至更差。

但是,如果是一件极其复杂的事情,小公司可能根本无法完成,大公司再慢,至少他们能搞定。

所以,我们的问题应该转化为:「如果一件事情,原本可以又快又好的完成,为何大公司却有那么多浪费?」

根本原因在于:大公司的管理模式,不够柔性化,不具备「伸缩性」。打个计算机服务器的比方:「当访问量增长的时候,我们可以不断添加服务器。但是,当访问量下降的时候,大家都忘记把服务器再撤下来了。」

四、为何大公司,快不起来了?

1. 高大上意识,小事情往往也会大张旗鼓的去做。
2. 风险意识,没有人敢说:「某某流程,大多数时候并无必要」
3. 参与意识,这件事怎么能与我们部门无关呢?
4. 自保意识,只要严格遵守流程,这个事情就算搞砸了,责任也不会在我身上。

归根结底,是缺乏不断改进的意识(或者换言之,公司大到某种程度,就算是想改进的人,也会面对深深的无力感)。

28万个开源项目之番外篇

一、工具

1. 数据抓取

最初是打算使用openhub.net的Open API的,他们有不错的API,还在Github上放了一个开源项目。只可惜,他们的API,最多申请5个API Key,每个Key明天的访问请求数量,不能超过1000次。当时我还不知道,其实openhub的数据只有28万多,还以为满打满算,至少得60多天才能全部抓完,顿时心就凉了。

后来有朋友介绍了一个很棒的直接抓取HTML页面,然后做DOM分析的工具,名叫noodle

接下来,只要抓取: https://www.openhub.net/p?ref=homepage&q=&page={num}
就能够拿到所有项目的概要数据了。

当然,后续的331个项目的明细数据,还是得通过OpenHub的API来抓取。

2. 数据分析

完全是土法上马:sqlite3+numbers+csv+ruby,反正各种手法,什么称手用什么。

3. 数据展示

原本是打算在numbers里想想办法的,后来发现实在太弱。Excel也差不多,只能到网上搜索一些信息图制作的工具,后来找到了几个不错的在线工具,经过一番比较,最后决定用infogr.am来完成。的确非常不错。

二、释疑:项目大小与创建时间的关系

我与@云风 在微博上有一小段讨论,起因还是我之前的一些分析的观点:

  • 是否使用Github,越是新的项目越愿意用;越是大的项目越没法用。
  • 是否使用Github来管理项目的issue,越是新的项目越愿意用;越是大的项目越没法用。

这个结论,其实在用词上,是有些讲究的:按理说,新与老相对,小与大相对;愿意与不愿意相对,能用与没法用相对,我的两个结论,对仗都不公整。其实,确实故意为之。

于是,云风与我的对话如下:
云风:项目规模和项目历史本身有相关性吧。代码规模越大的项目历史很可能越久。
我:项目的规模,主要还是与项目本身的特性有关。原本就复杂的项目,才可能越长越大。原本就是小项目,也未必就会稳定的逐年增长。
云风:这只能说明小项目可以历史久,不能说明大项目可以历史短啊。很少有新项目一开始就很大啊。代码也是一行行写出来的啊。
我:那就是成长速度不同了。比如OpenStack,一开始就不小。
云风:一开始就不小只能说闭源开发过一段时间,或从别的地方搬迁过来的吧。你能想象不被版本管理工具管理的情况下,首次提交 10 万行以上的代码?看这个 link 提交日志写的 initial fork out of nova。

后来,我也没有再继续这个讨论,但是却一直在思考这个问题:「项目的大小,与项目的创建时间,究竟有大少相关性?」

后来,我将两个数据,做了一个分析:Log(第一次提交代码,至今的天数)/Log(代码行数),大概得到如下一个图:

经过强大的Excel的计算,两个数据的相关系数,大约是0.203的样子,也就是说:大致上有较弱的正相关。

三、开源

目前,我已经将这个分析的相关数据,放在Github上开源了。简单介绍一下:

data.sqlite3.zip 是28万基础数据
projects.sqlite3 是331个项目的详细数据
projects.csv 是我用来做数据分析的大表格

四、名单

331一个开源项目,名单如下:

Name Homepage
Metasploit Framework http://www.metasploit.com/framework/
NetBSD http://www.netbsd.org
GNU C Library http://www.gnu.org/software/libc/
cURL http://curl.haxx.se/
Python programming language https://www.python.org
Linux Kernel http://kernel.org/
GNU Emacs http://www.gnu.org/software/emacs
gnulib http://savannah.gnu.org/projects/gnulib/
GNU Core Utilities http://savannah.gnu.org/projects/coreutils/
GNU Compiler Collection http://gcc.gnu.org/
Wine http://www.winehq.org
Debian http://www.debian.org/
GNU Octave http://www.octave.org
Visualization Toolkit http://www.vtk.org
pf http://www.benzedrine.cx/pf.html
GDB http://www.gnu.org/software/gdb/
GNU binutils http://www.gnu.org/software/binutils/
GHC http://haskell.org/ghc/
Zope http://zope2.zope.org
FreeBSD https://github.com/trueos/trueos
Perl http://www.perl.org/
GNU LilyPond Music Typesetter http://lilypond.org/
Gnus http://gnus.org/
ikiwiki https://github.com/schmonz/ikiwiki
Samba http://www.samba.org
PHP http://php.net
FreeBSD Ports http://www.freebsd.org/ports/
pkgsrc: The NetBSD Packages Collection http://www.pkgsrc.org/
Mesa http://www.mesa3d.org/
Squid Cache http://www.squid-cache.org/
KDElibs (KDE) http://www.kde.org/
gedit http://www.gnome.org/projects/gedit/
Evolution http://www.gnome.org/projects/evolution/
Kontact http://kontact.org/
KDE PIM http://pim.kde.org
Advanced Linux Sound Architecture (ALSA) http://www.alsa-project.org/
Wireshark http://www.wireshark.org
OpenSSL http://www.openssl.org/
GIMP http://www.gimp.org/
NetBeans IDE http://www.netbeans.org
Koha Library Automation Package http://www.koha-community.org
openSUSE Linux http://www.opensuse.org/
Doxygen http://doxygen.org/
libcurl http://curl.haxx.se/libcurl
GStreamer http://github.com/zaheerm/gst-plugins-good
GNOME http://www.gnome.org/
Insight Toolkit http://www.itk.org
zsh http://zsh.sourceforge.net/
Nautilus https://wiki.gnome.org/Apps/Nautilus
X.Org http://www.x.org/wiki/
Mozilla Core http://www.ahrcloud.com
MariaDB http://mariadb.org/
CMake http://www.cmake.org
LibreOffice http://www.libreoffice.org
ALT Linux http://www.altlinux.org
ParaView http://www.paraview.org
GTK+ http://www.gtk.org/
Poedit http://www.poedit.net/
Bugzilla http://www.bugzilla.org/
Enlightenment (window manager) http://www.enlightenment.org
FFmpeg http://www.ffmpeg.org/
GLib http://library.gnome.org/devel/glib/
PEAR http://pear.php.net/
Ruby http://www.ruby-lang.org/
GnuCash http://www.gnucash.org/
phpMyAdmin http://www.phpmyadmin.net/
Mono http://www.mono-project.com
SWIG http://www.swig.org
SWT (Standard Widget Toolkit) http://www.eclipse.org/swt/
Checkstyle http://checkstyle.sourceforge.net
Eclipse Java Development Tools (JDT) http://www.eclipse.org/jdt/
Eclipse Platform Project http://www.eclipse.org/eclipse/platform-ui/
Natural Language Toolkit (NLTK) http://www.nltk.org
Ekiga http://ekiga.org/
Boost C++ Libraries http://www.boost.org
Kate (KDE) http://kate-editor.org
Devhelp http://live.gnome.org/devhelp
Arch Linux Packages http://www.archlinux.org
SPIP http://www.spip.net
GNOME Terminal https://help.gnome.org/users/gnome-terminal/stable/
ScummVM http://www.scummvm.org/
Anjuta DevStudio http://anjuta.org
BlueZ http://www.bluez.org/
Eye of GNOME http://www.gnome.org/projects/eog
Tor http://www.torproject.org/
Fedora Packages http://fedoraproject.org
Haiku http://www.haiku-os.org
Stellarium http://stellarium.org/
Totem http://projects.gnome.org/totem/
Rhythmbox http://www.gnome.org/projects/rhythmbox/
Gentoo Linux http://www.gentoo.org/
CDT (Eclipse) http://www.eclipse.org/cdt/
JRuby http://www.jruby.org
eZ Publish http://share.ez.no
VLC media player http://videolan.org/
Equinox http://www.eclipse.org/equinox/
Epiphany http://www.gnome.org/projects/epiphany/
Thunderbird http://mozilla.org/thunderbird/
GeoTools http://geotools.org
PyPy http://pypy.org
KDE http://www.kde.org
apt – Advanced Package Tool https://wiki.debian.org/Apt
Moodle http://git.moodle.org/gw?p=moodle.git
Calligra Suite http://www.calligra.org
QGIS http://qgis.org/
Mozilla Firefox http://www.firefox.com/
coreboot http://www.coreboot.org/Welcome_to_coreboot
Tiki Wiki CMS Groupware http://tiki.org
Apache Maven 2 http://github.com/apache/maven-archetype
Plone http://plone.org
Superior Lisp Interaction Mode for Emacs http://common-lisp.net/project/slime/
Kodi http://kodi.tv
MythTV http://www.mythtv.org
systemd http://www.freedesktop.org/wiki/Software/systemd
GeoServer http://www.geoserver.org
Groovy http://groovy.codehaus.org/
Blender http://www.blender.org/
MySQL http://www.mysql.com/
iproute2 http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
MonoDevelop http://www.monodevelop.com
Hibernate http://www.hibernate.org/subprojects/ogm
NetworkManager http://www.gnome.org/projects/NetworkManager/
NLog – Advanced .NET Logging http://nlog-project.org/
GParted http://gparted.org/
Seahorse http://www.gnome.org/projects/seahorse/
Glade User Interface Designer http://glade.gnome.org/
Jenkins http://jenkins-ci.org/
IntelliJ IDEA Community Edition http://www.jetbrains.org
Ruby on Rails http://rubyonrails.org
BusyBox http://busybox.net/
Evince http://projects.gnome.org/evince/
DokuWiki http://www.dokuwiki.org/
Linux NTFS file system support http://www.linux-ntfs.org/
KVM http://kvm.qumranet.com/kvmwiki
Battle for Wesnoth http://wesnoth.org/
Git http://git-scm.com/
SPIP-Zone http://zone.spip.org/trac/spip-zone/
Mercurial http://mercurial.selenic.com/
Hibernate Entity Manager http://entitymanager.hibernate.org/
Racket http://racket-lang.org/
RubyGems http://rubygems.org
SQLAlchemy http://www.sqlalchemy.org/
cabal http://haskell.org/cabal/
U-Boot http://www.denx.de/wiki/U-Boot/WebHome
WebKit http://webkit.org
OpenEmbedded http://openembedded.org
Yocto Project http://www.yoctoproject.org
matplotlib http://matplotlib.org/
Symfony http://www.symfony.com/
Meld http://meldmerge.org/
Haxe http://haxe.org/
FreeSWITCH http://www.freeswitch.org/
Geany http://geany.org/
collectd http://collectd.org/
Gramps http://gramps-project.org
phpBB Forum Software http://www.phpbb.com/
HAProxy http://www.haproxy.org/
fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page
NumPy http://numpy.scipy.org
Scala http://www.scala-lang.org/
dpkg http://wiki.debian.org/Teams/Dpkg/
Nette Framework http://nette.org
Inkscape http://www.inkscape.org
Phing http://www.phing.info/
jBPM http://jbpm.org
JBoss Drools http://www.jboss.org/drools
Bitbake http://developer.berlios.de/projects/bitbake/
Zotero http://www.zotero.org/
Lutece http://www.lutece.paris.fr
OTRS http://www.otrs.com/
Sage: Open Source Mathematics Software http://sagemath.org
Rockbox http://rockbox.org
Liferay Portal http://liferay.com
TYPO3 CMS http://typo3.org
Vala http://live.gnome.org/Vala
pylint http://pylint.org
The LLVM Compiler Infrastructure http://llvm.org/
libvirt http://libvirt.org
TinyMCE http://tinymce.moxiecode.com
Django http://www.djangoproject.com/
PHPUnit http://www.phpunit.de/
OpenStreetMap http://www.openstreetmap.org/
SymPy http://sympy.org
Xen Project (Hypervisor) http://www.xenproject.org
Eclipse Mylyn http://www.eclipse.org/mylyn/
PHP_CodeSniffer http://pear.php.net/package/PHP_CodeSniffer
Sakai LMS (core) http://www.sakaiproject.org/
Spring Framework http://github.com/SpringSource/spring-framework
Joomla! http://www.joomla.org/
Marble http://edu.kde.org/marble/
LXDE http://lxde.org
Pygments http://pygments.org/
OpenLayers http://openlayers.org/
The MacPorts Project http://www.macports.org/
calibre http://calibre-ebook.com/
Grails http://grails.org
Alfresco Content Management http://www.alfresco.com
util-linux https://github.com/karelzak/util-linux
jQuery http://jquery.com/
Vaadin http://vaadin.com/
Cython http://www.cython.org/
Dojo Toolkit http://dojotoolkit.org/
MediaWiki https://www.mediawiki.org/wiki/MediaWiki
Second Life Viewer http://www.secondlife.com/
Munin http://munin-monitoring.org/
Odoo https://www.odoo.com
Mozilla Calendar http://www.mozilla.org/projects/calendar/
KDevelop http://kdevelop.org/
ZNC http://znc.in
Werkzeug http://werkzeug.pocoo.org/
cppcheck http://cppcheck.sourceforge.net/
Wicket Stuff http://wicketstuff.org
Drush http://drupal.org/project/drush
Sphinx documentation builder http://sphinx-doc.org/
Piwik http://piwik.org
JDownloader http://www.jdownloader.org
SeaMonkey http://www.seamonkey-project.org/
Empathy http://live.gnome.org/Empathy
SilverStripe http://www.silverstripe.org
PulseAudio http://pulseaudio.org
LLVM/Clang C family frontend http://clang.llvm.org/
Pylons http://pylonsproject.org
MongoDB http://www.mongodb.org/
Mockito https://github.com/mockito/mockito
Doctrine http://www.doctrine-project.org
Pacman http://www.archlinux.org/pacman/
MAME – Multiple Arcade Machine Emulator http://mamedev.org/
Rubinius http://rubini.us/
Apache Camel http://camel.apache.org/
OpenJDK http://openjdk.java.net/
Buildbot http://buildbot.net/trac
MPD http://sourceforge.net/projects/musicpd
Tracker http://projects.gnome.org/tracker/
org-mode http://orgmode.org
Sass http://sass-lang.com/
WPA/WPA2/IEEE 802.1X Supplicant http://hostap.epitest.fi/wpa_supplicant/
Go programming language http://golang.org/
Apache CouchDB http://couchdb.apache.org/
Qt 4 http://qt-project.org/
Apache CXF http://cxf.apache.org/
CakePHP http://cakephp.org
CKeditor WYSIWYG editor http://ckeditor.com/
SciPy http://www.scipy.org
gitg http://trac.novowork.com/gitg/
Banshee http://banshee-project.org
OGRE http://www.ogre3d.org
Chromium (Google Chrome) http://code.google.com/chromium/
Gradle http://www.gradle.org/
Netty Project http://netty.io/
Sinatra http://www.sinatrarb.com
Chef http://www.opscode.com/chef
Gerrit Code Review http://code.google.com/p/gerrit
GNOME Shell http://live.gnome.org/GnomeShell
Git Extensions http://code.google.com/p/gitextensions
Qt Creator http://qt-project.org/
Kohana v3 http://kohanaframework.org/
Android http://www.android.com
JUnit http://www.junit.org
PCSX2 http://pcsx2.net/
Shotwell https://wiki.gnome.org/Apps/Shotwell
Redis http://redis.io/
Cassandra http://cassandra.apache.org/
PhoneGap http://phonegap.com/
Trinity Core http://www.trinitycore.org
Icinga http://www.icinga.org
CyanogenMod http://www.cyanogenmod.com/
Rygel http://live.gnome.org/Rygel
QEMU http://www.qemu.org/
Trinity Core2 http://www.trinitycore.org
Pitivi http://github.com/jhoolmans
Openfire http://www.igniterealtime.org/projects/openfire/
Apache Hadoop http://hadoop.apache.org/core/
akka http://akka.io
JGit http://www.eclipse.org/jgit/
Homebrew https://github.com/Homebrew/homebrew-apache
Oh My Zsh http://github.com/robbyrussell/oh-my-zsh
ehcache http://www.ehcache.org/
EGit http://www.eclipse.org/egit/
node.js (NodeJs) http://nodejs.org
Thunar http://www.xfce.org
Selenium http://seleniumhq.org/
Arquillian http://jboss.org/arquillian
Erlang http://www.erlang.org
YUI http://yuilibrary.com/
Gunicorn http://gunicorn.org
CoffeeScript http://www.coffeescript.org/
Clementine Music Player https://github.com/clementine-player/Clementine
scikit learn http://scikit-learn.org
Processing http://processing.org/
Vagrant http://vagrantup.com/
Qt 5 http://www.qt-project.org/
Yii PHP Framework http://www.yiiframework.com
Zend Framework http://framework.zend.com/
Apache Spark http://spark.apache.org
Flask http://flask.pocoo.org/
OsmAnd http://www.osmand.net
ownCloud http://ownCloud.org
Open Computer Vision Library (OpenCV) http://opencv.org/
phpDocumentor http://www.phpdoc.org
IPython http://ipython.org/
RSpec http://rspec.info/
OpenStack http://www.openstack.org/
OpenStack Nova https://launchpad.net/nova
Apache CloudStack https://github.com/apache/incubator-cloudstack
AngularJS http://angularjs.org/
GWT (formerly Google Web Toolkit) https://github.com/google-web-toolkit/gwt
Facter http://puppetlabs.com/puppet/related-projects/facter/
salt http://saltstack.org
jMonkey Engine http://jmonkeyengine.org
Puppet http://puppetlabs.com/puppet/
Play! framework http://www.playframework.org/
Elasticsearch http://www.elasticsearch.com
Bootstrap (Twitter) http://twitter.github.com/bootstrap/
Apache OpenOffice http://www.openoffice.org/
GlassFish https://glassfish.dev.java.net/
Propel http://propelorm.org
JabRef http://jabref.sourceforge.net
CodeIgniter http://www.codeigniter.com/
GNOME Boxes http://live.gnome.org/Boxes
GitLab https://www.gitlab.com/gitlab-ce/
TiddlyWiki http://www.tiddlywiki.org
Fish shell https://github.com/fish-shell/fish-shell
Ansible http://ansible.com
Simple Machines Forum http://www.simplemachines.org/
FontForge http://www.fontforge.org
libgdx http://libgdx.badlogicgames.com
py-pandas http://pandas.sourceforge.net/
javascript https://github.com/airbnb/javascript
EasyTAG https://wiki.gnome.org/Apps/EasyTAG
docker http://docker.io
Capistrano http://capistranorb.com/

从28万个开源项目中,我们能够学到一些什么?

引子:开源项目那么多,哪些是值得我们学习的?

这里声明一下,仅仅是学习一下:他们是用哪些工具,来管理自己的项目的?

开源项目多如牛毛,值得分析的项目也很多很多。从哪里入手呢?幸运的是,在开源社区,有一个著名的网站,过去叫oloho,现在改名叫openhub。在他的网站首页,有这么四行字,以表明他们的数据库是多么的全面、丰富:

Indexing 669,008 open source projects
Connecting 3,742,793 open source contributors
Tracking 679,761 source control repositories
Counting 31,158,335,454 lines of code

这么说来,事情就变得比较“简单”了,我需要把openhub的数据,都抓回来。


数据的筛选过程

具体的数据抓取过程,简直不忍详述(我的内心,几乎是崩溃的)。总而言之,我只抓到了289,631个项目。openhub虽然号称自己索引了66万的开源项目,其实这仅仅是他的数据库里的最大ID号!当我顺着这个ID一个一个的去抓的时候,有很多ID,都已经被删除了。

在抓取到的项目数据中,有两个数值,特别值得参考:contributors(参与开发者的数量);users(该软件的用户数量)。相对而言,users的数据,可以认为是一个样本,即该开源项目的所有用户中,愿意并且知道该如何来openhub点击I use this的人。因此,即使是排名第一的Firefox,在openhub也只有13158个用户。考虑到Firefox的用户数,已经超过5亿(来源于维基百科英文版),因此,我们相信这个数据仅仅是一个4万分之一的采样结果。

随后,我观察了这28万多个项目的users数据与contributors数据,顿时惊讶的发现,绝大多数项目,都小的可怜,用户也少得可怜。

当我以“select count(*) from projects where contributors>30”查询时,只搜到了  1662个项目...
当我以“select count(*) from projects where users>30”查询时,只搜到了1260个项目...
当我合并以上两个条件查询时,只搜到了335个项目。
再从这335个项目中,排除掉最近一年已经不再有活动的项目,于是只剩下了331个了。

三个感想

  1. 成功的开源项目,真是凤毛麟角
  2. 绝大多数开源项目都是少数人开发的小项目
  3. 这331个项目,也许可以作为我们的重要参考

第一个问题:他们用什么配置库?

这是331个项目,使用配置库的情况(有些项目,同时使用多种配置库),有两个现象值得注意:

  1. 接近92%的项目,已经在使用git——git的统治地位,已经无可动摇
  2. 只有53%的项目,在使用Github——那些用git却不用Github的项目,是什么原因?

通过数据来分析:是否使用Github与项目创建时间的关系

通过这个图,可以看出两个现象:

  1. 越是新创建的开源项目,hosting在Github上比例越高
  2. 越是新创建的开源项目,事实上成功的也越多(当然,2010年以后的数量锐减,我们怀疑是好酒也要陈酿的原因)

通过数据来分析:是否使用Github与项目代码规模的关系

由于不同的开源项目,代码行数差异巨大,因此我们只能以log(col)对数结果,来做区间划分。可以看到一个非常明显的趋势,当然代码行数超过10万行以后,代码部署在Github上的项目,就开始明显下降,直到为0。

总结:是否使用Github,越是新的项目越愿意用;越是大的项目越没法用。


第二个问题:他们用什么来管理issue?

排名前五的工具中,Github:91个项目;Bugzilla:81个项目;JIRA:43个项目;Trac:20个项目;另外还有9个项目,完全是在maillist里“管理”issue的。

一共有39种不同的工具,另外还有6个项目,我们无法了解他究竟是用什么来管理的。

简单的来看:

  1. Github已经占据统治地位
  2. Github的占有率仅仅27%。
  3. Bugzilla也算老而弥坚
  4. 有很多项目,在选择自己的工具

通过数据来分析:使用的issue tracking工具与项目创建时间的关系

1990年之前创建的项目,其中有一个已经开始使用Github了。但是,这仅仅算是个案。更加明显的趋势是:越是新的项目,越是倾向于采用Github管理自己的issue。

相对而言,其他各种Issue Tracking工具的比例,都在下降。

通过数据来分析:使用的issue tracking工具与项目规模的关系

随着用户数量的增加,我们猜想:issue的数量与复杂度,也会逐渐增加。可以看到这样的趋势:Github的使用率,也在不断下降。

总结:是否使用Github来管理项目的issue,越是新的项目越愿意用;越是大的项目越没法用。


尚未完成的分析:

  • 开源项目使用的CI工具的情况
  • 开源项目使用的Code Review工具的情况
  • 开源项目使用的文档类工具的情况
  • ……

主要还是工作量太大了。。。对这个分析有兴趣的同学,可以与我联系,咱们可以一块来干。

Free Software vs. Open Source

首先推荐一部电视剧

很早以前看过一部港剧《龙兄鼠弟》,是万梓良、郑则仕和张卫健演的。其中万梓良饰演的雷文凤,在最后写了一本书,叫做《黑白灰》。大意是:这个世界,虽然存在黑白两色,绝大多数人,却都是灰色的。而他,却一定要坚持做一个纯白色的人。甚至在他看来,灰色的人,较之黑色的人,更加罪恶。

最近刚刚读完了另外一本书《若为自由故》,则是一本Richard Stallman的传记。在这本书里,红帽公司总裁罗伯特·杨(Robert Young)总结理查德看似矛盾的政治行为时,说道:“我崇拜也尊敬理查德和他所做的一切。我对他唯一的批评就是,有些时候,他对待朋友甚至比对待敌人还要无情。”

在我看来,也许发起开源运动的那群人,大多数自认为是RMS的朋友,而对于RMS而言,他们只是一群放弃了原则而站在灰色地带的人罢了。

说实话,在自由软件与开源之间,我究竟应该持何种立场?这是一个,我一直以来,都不愿意深想的问题,实在是太难了。只是这回读了一遍RMS亲笔签名的个人传记,又了解到了很多当事人的实际言论,总觉得应该督促自己,思考出一个结论出来。

两者的分歧,首先是哲学上的:理想主义 vs. 实用主义

在RMS看来,自由是天赋人权,可以说:因为自由本身值得追求,而RMS恰好又是个软件天才,所以他才会致力于自由软件。

而在开源运动看来:吸引更多的人参与自由软件的开发,然后实实在在的拿出优秀的开源软件来,才是真正有价值的事情。

自由软件的目的,是更多的自由,而开源软件的目的,是更好的软件

GPL是一种神奇的创造

如果RMS只是一位致力于追求软件自由的斗士,也许不会有任何人理睬他。但是他写出了Emacs、GCC这样的神级软件。以至于由此建立起了几乎无人能及的社区影响力。

因为他写的软件实在太牛,所以无论他以什么样的License来发表自己的软件,都会引发全社区的关注。

然后,GPL这种诡异的授权模式,才会有人愿意遵循。甚至,应用作为自己的开源License。

或者换句话说:RMS挂了Emacs的羊头,卖了GPL的狗肉。但是,Emacs这个羊头实在太好,买了GPL这种狗肉的人,居然也就认可了。

《大教堂与集市》对于RMS是一个重大打击

因为《大教堂与集市》一书,对于Linux成功之道的总结与宣传,使得Linus被人们提升到了世界上最知名黑客的行列。

说到底,在黑客这个圈子里,大家还是更注重实力,而非理念。当有人以完全不同的方式,创造出完全不逊于Emacs、GCC这样的开源软件时,RMS/自由软件/大教堂所代表的「道路」,就不再是唯一的选择了。

尤其是当Linus站在了开源的大旗下,更多的公司则出现在了Linux的周围。集市的胜利,不仅仅是开源相对于闭源的胜利,也是Linus相对于RMS的胜利。

在之后的世界里,虽然开源的代码越来越多,但是自由却越来越少被人提及了。

不完美的系统会激怒黑客

公正——该如何做是好》一书中,有一个经典的伦理学命题:假设铁轨上有一辆失控的火车,在岔路的一边是一个人,而另一边则是五个人。你是一个扳道工,你会选择让火车开向一个人,还是五个人?

我曾经问过我儿子这个问题,他的回答非常有趣:「如果是五个大人,与一个大人」,那就撞一个大人。「如果是五个大人,与一个小孩」,那就撞五个大人。「如果是五个男人,与一个女人」,那就撞五个男人。「如果是五个男人,与一个胖女人」,那就撞那个胖女人。。。

这其实反应了一个事实:想要通过权衡利弊,来做出最有利的选择,可能会是非常没有原则的事情。即使是一个成年人,也未必能做得有多好。

对于一个像RMS这样的黑客来说:他们会被这种问题所激怒,进而会拒绝回答问题,并想尽一切办法,要hack掉这个该死的列车与轨道系统。

在本书的第十二章《开往黑客地狱的短暂旅途》,就讲了一个令RMS暴怒的故事,在书中,作者写到:「“不完美的系统会激怒黑客。”史蒂芬·李维说过 这样的话,这是我决定与斯托曼同坐一辆车前应该听取的另一个忠告,“这是黑客们通常不喜欢开车的原因之一:这是一个充满不确定性的程序,交通信号灯总是随 机的变化,还有横七竖八的单行道,导致交通经常堵塞。这实在是太不必要了,只要让黑客们重新安排一下信号灯,打开交通灯控制盒,重新设计整个系统。”」

是的,对于真正的黑客来说:适应这个不完美的世界——取舍、权衡、妥协,是别人的事情。而黑客,就一定想要改造它!

我的结论

RMS这样的人,就像是在遥远的天边,在夕阳即将落下之时,努力为我们撑起天际线上那最后一点光明的人。

我没有资格自称为黑客。哪怕是改变世界的念头,我也常常是一闪而过。但是,这并不妨碍我始终对RMS,报以最高的崇敬!

至于Open Source,那至少是个很不坏的东西吧!

如何评价一个新技术——以Docker为例

上次与霍炬聊天,霍炬提到他在跟陈皓抬杠,陈皓认为Docker与Java是一个级别的发明,第二年就吸引了所有热门公司的加入。而霍炬认为这太夸张了,毕竟就是个配置管理器嘛。

而我的评价,可能会比陈皓的更高,我认为Docker比Java的级别还要高。而且,这与有多少公司参与无关。甚至可以反过来说:因为Docker极为重要,才会有那么多的公司,在第一时间加入进来。

因此,我也答应霍炬,要写一篇文章,仔细的阐述一下自己的观点。

新技术的三大功效

新技术的三大功效

新技术的三大功效:

  • 提升效率:某种更快的算法

或者更快、或者更省,都是好技术。可以是一个算法,也可以是一种更方便快速开发的框架。可以是更高速的网络带宽,也可以是更省电的低功耗技术。

这些,当然都是极好的。但是,也都不过是某种层面的量变而已。除非提升的幅度,达到百倍、甚至千倍、万倍。

  • 增加选择:一种新的语言

有时候,我们会把这类行为称之为重新造轮子。然而,我们也可以认为,哪怕是做同一件事情,现在也多了一种新的选择。

当然,这并非其价值所在。更重要的益处在于:新的选择,意味着新的思路,新的模式,新的「解法」。

虽然,在做这件事情本身,也许并无太多帮助。但是,却可能启发新的创造。

  • 降低门槛:更加简单的工具

有一类技术,并非直接的贡献,而是间接的。原本在这个领域,非要苦学十年以上,才能出师。现在,21天,就能从入门到精通了。以前只有国际巨头才能开发的移动电话,现在一个英语教师,就敢开整了。

但是,降低门槛的技术,往往具有颠覆性的价值。一个行业,只有100人能参与,和有100万人能参与,将会带来绝对意义上的不同。很多时候,虽然降低门槛,并不能真正化解深层次的复杂性。但是,却会吸引更多的聪明人,来一起思考和解决问题。

繁荣之后,一切皆有可能。

如何给docker定位?

  • docker所封装的容器技术,带来了更高的效率
  • 以docker容器为代表的虚拟化模式,是一种新的选择,将为架构设计带来新的启发
  • docker-registry、dockerfile、docker-compose等相关技术,大大降低了参与到这一容器化浪潮的门槛

综上所述:我认为docker是一种极具潜力的新技术。正因为其潜力巨大,才吸引了众多巨头、众多企业、众多散户以及众多一线研发者的共同热捧。

题外话

事实上,我上面画的那个模型,是自己生造的。甚至可以算是为Docker度身定制的。在以上三个要素之外,还有其他一些评价新技术的标准。

从量变到质变

这是我上面刻意模糊的部分。一个技术,能够快2倍、20倍、还是20万倍。将会得到完全不同的评价。

飞行速度是否能超过7.9公里/秒,是完全不同的两重境界。

创造一个新行业,甚至更多行业

在电视机出现之前,不会有电视演员,不会有现场直播,不会有主持人,不会有…沙发土豆。

能够令整个世界因此而不同的新技术。岂是小小的docker可比?

危害性

似乎,IT行业最牛的技术,也不太会有啥危害性。前一阵热炒的人工智能,也不过是某种夸张100倍之后的危言耸听而已。

毕竟,一种新技术,都无法威胁世界和平,能有多了不起?比起物理学家、化学家,咱们这些搞IT的人,简直弱爆了。

不会太灰暗的未来

霍炬前阵子写了一篇「歪理邪说」:《无论强人工智能能否出现,人类的未来注定灰暗》我第一遍阅读的时候,发了一条微信:「好一篇歪理邪说,一时间竟无法反驳」。潜台词是:总觉得有哪里不对,还是很想反驳的。。。

简单总结霍炬的观点,我认为主要包含以下两点:人们无意识地,甚至主动的分享自己的隐私;这些隐私被大公司掌握,辅之以大数据分析,以深度学习的方式理解用户,进而对人类行为实现操控。

在经过几周的思考之后,我打算将自己的观点表达如下:

1. 我的隐私,我自己都知道吗?

在没有查看网站访问日志之前,我根本不记得自己一天看了多少网站,浏览了多少内容。在没有佩戴智能手环之前,我不知道自己每天走了多少步路。在手机没有GPS定位功能之前,我甚至会偶尔迷路,不知道自己身在何处。

当然,我每天浏览的网站,走了多少路,心跳水平,吃了什么,去了哪里,都是可以算作我自己的隐私。但是,我要么自己根本不知道,或者因为信息琐碎,我自己也记不住。

那么,这些我自己都搞不清楚的隐私,还算是隐私吗?如果,这些隐私没有别人知道,我自己也不知道,这种隐私,有什么价值呢?如果是没有价值的隐私,有保护的必要吗?

换句话说,如果我上传了这些隐私(我原来自己都不知道的隐私),给我带来了更多的收益,这个是不是好事呢?

2. 基于隐私的增值服务,存在诸多灰色地带

众多的服务,哪怕是传统服务,也需要了解用户的隐私。我去做按摩,我的按摩师傅会问我:你最近哪里不太舒服。去医院看病,负责任的医生也会询问我的既往病史。如果不了解这些信息,他们就无法提供针对我的服务。

进入网络时代,我们会向从未见过的人,甚至某个网站,透露自己的隐私。我们的信用卡号,我们的身份证和年龄性别。如果我们想要去网上征婚,那还得填写更多的内容。

为什么我们愿意主动填写这些信息?因为需要换取更好的服务。

再进一步,针对一个人的数据,力量是不足的。如果网站能够收集足够多人的数据,统计、分析、甚至预测。假设:根据不同地区,针对不同商品的搜索频率,预测不同地区的商品需求趋势。这当然能够帮助商家赚取更高的利润。但是也的确能够让用户在下单购买时,以更快的速度,收到货物。

如果,网站在收集这些需求数据的时候,能够只做汇总,不记明细。那么,用户来说,就只有益处,没有损害了。

事实上,所谓隐私,是针对不同的个人意愿而界定的。我的个人信息,如果我不愿意他人知道,那就是我的隐私。如果,我不介意他人知道,那就不是隐私。

不过,我想要举一个非常令人困扰的例子:「我在微信或者微博上,分享自己孩子的照片,甚至还有姓名和乳名。这是不是会存在问题?」很多爸爸妈妈都在这么干,而且往往乐此不疲。另一方面,也有很多「有识之士」指出:「这会给人贩子、诈骗犯、敲诈勒索的绑匪以可乘之机!」

甚至,如果存在某个刻意针对你的家伙,默默收集你的各种公开信息,就能做到对你了如指掌,进而对你不利。在过去,他可能需要去翻你家的垃圾桶,再私下找你的身边人打听。现在,他们坐在家里,就能够搜集到这一切。甚至,有某种地下的黑色产业链,在兜售各种隐私的信息,以方便他购买。

问题在于:我不介意他人知道的一些个人信息,究竟是否有可能损害我的利益?而我在交出这些信息的时候,是否已经知道这一点?假设,我们公开分享的所有信息,事实上都可能对我们不利,这样的概率有多大?我们应该放心大胆的分享吗?还是应该不怕一万、就怕万一?

3. 权利的转让与契约的成立

如果跳出IT、网络以及隐私的范畴,我们可以找到另外一些相近的例子——国家与政府的出现。在国家与政府出现之前,人类比现在自由得多,当然,也短命得多。安全没有保障,随时可能被人干掉。人们居住的地方,也缺乏各种公共设施,没有路灯,没有医院,没有警察,没有城管,没有环保局,没有……

没有这些公共的服务,人类自然都朝不保夕,直到他们愿意让渡自己的一部分权利,教给一个公共的政府,由这个政府,提供各项公众需要的服务。

当然,一旦政府出现,就有了自己的生命力,甚至可能违背创立者的本意。这才是需要监督政府的根本原因。让渡权利,订立契约,保持监督。这就是现代国家的「契约论」基石。

西方的众多知识分子,有一个永恒的命题:「警惕政府走向独裁」。但是,无论多么警惕,无论多么强调监督,「取消政府」的言论,绝非主流。也不可能成为主流。

回到隐私的话题上来。我们上传自己的隐私,同样是基于我们与服务商之间的「契约」的。也许我们通常不看那些契约的文字,也许我们往往不关心可能的条文陷阱,也许我们的信息,会落入不怀好意的人手中。但是,我们已经无法回到过去,无法停止使用众多的网络服务,无法放弃在朋友圈发照片了。

唯一的选择,只能依赖法制,持续向前。如果法制不健全,就推动法制的健全,推动对服务商的监管,如此而已。

那种担忧人类注定会走向灰暗未来的心态,与担忧人类早晚会落入独裁者之手的心态一样。是相当「杞人忧天」的。

4. 借助工具,认识自己?

「认识你自己」,这是古老西方的格言。「人贵有自知之明」,这是古老东方的格言。问题在于,如何才能做到呢?在传统的方法中「反思、静观、禅修」,也许是可行的办法。在科学昌明的现代,也许工具可以帮助我们。

在霍炬的文章里,有一个很有趣的「近未来幻想」,可以通过分析购物者的心跳、血压等身理特征,判断对于这个人最具有吸引力的商品价格。

这其中有啥问题吗?以这种价格购买这种商品,违背了用户的意愿了吗?根据不同的供求关系,确定销售价格,原本就是「政治正确」的经济学规律。那么,在大数据支撑之下,商品能够根据每一个个体的需求强烈程度,确立一个针对性的价格,不是更加符合经济学规律吗?

假设通过机器的分析,我们掌握了用户的真实需求强度,这究竟是一种操纵,还是一种迎合呢?

假设,我们通过个性化推荐,列出了用户真正想要的商品,用户会因此感到恐慌吗?假设,我们不是以程序方式揣摩用户心理,而是由一个经验丰富的导购小姐,带领用户完成选购,是不是就不会令人恐慌了呢?

那么,我们恐慌的,是不是「程序而非人类,猜出了我的心意」这一事实呢?

血压计、心电图、X光机,种种医学手段,帮我们更加真实的掌握自己的健康状况,当然也能够帮助我们发现疾病,尽快恢复健康,延长寿命。那么,如果随着科技的发达,某种机器和算法,能够帮助我们更加深入的认识自己,了解自己,这样会带来什么样的益处(坏处)呢?

5. 怎么才算作被操控?怎么才算作被洗脑?怎么才算作被决策?

任何人都害怕自己被人操纵,当然,更糟糕的是被机器操纵。问题在于,怎么才算是被操纵、被洗脑、被决策呢?

当年在知乎,我曾经回答过一个类似的问题。简单说:「过程中是否可以反悔;事后是否可能后悔」。

我们在网上购物,购得兴高采烈,事后又号称自己要剁手云云。我也没听说过有几个人,真正的剁了手。如果商家提供了7天无理由退货,在7天之后,你还没有退货。那就不要说自己是被操纵购物的。

霍炬文中的有一段话,可以算作是一种惊人的预言:「那时候人们就会有更多行为会按照人工智能程序所规定的方式进行,并且,还会发自内心的认为那是他独立自主的产生想法。人会完全会成为程序的终端,为程序贡献数据,按照程序引导产生行为,依赖程序生活和工作。」

在我看来,这段话称得上是危言耸听。背后的逻辑,是对技术深深的恐惧。

6. 人是生而自由的,却无往不在枷锁之中。

在没有任何技术介入的情况下,我们从一生下来开始,就会受到引导、规劝、甚至强制教育。父母会告诉我们,这样做是对的,那样做是错的。如果干了某些事,就一定会挨揍。

在上学以后,我们读书、学习,书本上,课堂上,老师的耳提面命,书中的价值灌输。什么样的少年,才是一个好少年?我们如何才能带上小红花?我们如何才能称为三好学生?我们如何才能当上班干部?

在生活中,小说、诗歌、散文、杂志,在向我们倾诉着各种不同的价值观。形形色色的广告,在以种种价值观,无所不用其极的诱导我们消费。身边的同学、同事、朋友、亲戚,也在不断的向我们传递他们的价值观。

我们一路行来,哪有一天躲得过呢?

三十而立、四十不惑,追求的无非是确立自己的价值观。我们不断学习、思考、总结、成长,无非是为了不受人惑、有自己的主见。

那些读完了霍炬的文章,认定人类的未来注定会灰暗的朋友,也许已经不自觉的接受了某种灌输。比起尚未到来的「人工智能操纵你的未来」,只怕已经被一篇文章洗了脑!

7. 未来真的会那么灰暗?

我一直觉得未来学家,是一种非常高大上的、安全的职业。当然,他们最好不要预测自己活着就能够看到的未来,免得到时候麻烦。

那篇引发了霍炬文章的「介绍强人工智能」的文章,其中的逻辑,也非常吊诡。如果未来机器的智商,是人类的成百上千倍,差距大到了蚂蚁与人类的差距。我们谁有资格预测未来呢?蚂蚁有资格预测人类社会未来的发展趋势吗?

与其勉强预测,写些危言耸听的文章。倒不如老老实实的承认:未来无法预测!把小说写得像科普文章,真的靠谱吗?

未来将从何而来?我不知道。在我看来「未来不会那么灰暗」,至于理由,也许是因为我比较乐观吧……

三代开源社区的协作模式

一、研发工具与研发模式

据说,人之区别于禽兽,最大的特征在于利用,甚至发明工具。在没有任何其他工具时,我们只能借助于自己的肢体,一旦有了工具之后,我们的能力将会大大的增加。

但是,从另一个角度来看,工具也同时在限制我们的能力,甚至限制了我们的行为模式与思维模式。有一句俗话说得好:「手里拿着锤子,看见什么都像钉子。」

而在研发工具的领域,我们观察到另外一些有趣的现象:因为软件研发工具的开发者,同时也是工具的使用者。因此,他们不仅仅会受制于工具,也往往会由 此被激发,开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一的现象,使得研发工具的发展,简直可以用「日新月异」、「层出不穷」甚至「争奇斗 艳」来形容。

随着软件复杂性的不断增加,以及软件开发的参与者不断增多,团队协作的辅助软件,也开始不断增加,随后我们发现:工具不仅仅限制了个人的行为模式,更进一步限制了团队的协作模式。

软件研发企业的管理者,往往会有某种错觉,他们会认为:管理就是定下制度、流程与规范,然后「下面的人」就会照此执行。因为有人「听话」,有人「不听话」,所以才需要奖励与惩罚的制度,来帮助管理者推行他的「规则」。所以,他们一般都很喜欢看《执行力》这样的书。

在开源社区,事情变得有些不一样。虽说开源社区也有「领导者」,甚至往往会有「精神领袖」,但他们并没有暴力手段,也没有经济手段,甚至行政手段。因此,要协调一帮自由散漫的黑客,共同开发高质量的开源软件,必须有更加高明的手段。

由于一切都是Open的,所以:不仅代码人人可见,开源社区的协作模式,也暴露在众目睽睽之下。从某种意义上来说:这促进了开源社区的协作工具的开发、进而使得开源的研发协作模式,以远远超过企业内部的演化速度飞速演化。

二、第一代开源协作模式

第一代开源协作模式,在早期几乎没有符合自身特殊需要的工具,有什么用什么,因此最为常用的email,被发展为Maillist,成为整个开发团 队的协作核心工具,大多数操作系统内置的diff/patch工具,使得代码的交流以email patch为主。这些老牌的开源项目,从使用RCS、CVS,到了后来也开始逐步引入svn/git,bugzilla这样的工具,但是围绕 mailing list开展协作的特征,则持久不变。

作为协作核心的Maillist

一个开源社区,往往就是一个邮件列表,随着软件的日益复杂,社区的不断扩大,邮件列表也会不断分化,通常会划分为:核心组、开发组、用户组。开发组与用户组的邮件列表,随着软件的架构分化为多个模块,还会进一步分解。

在邮件列表里,所有的用户都是平等的,在无法用工具保障流程的情况下,社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规范的邮件,不会被理睬;不礼貌的家伙,甚至会被赶走。

邮件越来越多,即使分成多个邮件列表,依然太多。Archive这样的邮件归档、查阅的工具,就必须得有了。一封邮件,大家都来回复,严格re:的标题,组成了一个可供追溯的线索。

在邮件列表里,通常出现个人的名称,加上Reported-By、Tested-By、Acked-By的标记,即是一种代表个人名义的认可,也是流程规范的一部分,更是计算各人贡献的依据。

Bugzilla应运而生

在邮件中,有一类话题是最活跃的,那就是bug。但是,通过翻找邮件查阅bug的最新的解决状况,是非常困难的。一个bug,从提出,到最终解决, 并被确认在哪一个版本中发布fix,是一种稳定的状态转化模式。一个专有的处理工具,势必应运而生。Bugzilla、trac等一批工具,就由此被创造 出来了。

代码提交流程的规范化

开源社区,表面上非常的崇尚民主自由,但实际上却盛行精英主义、甚至是个人独裁的。我们往往会给某个开源项目的创始人,冠以「仁慈的独裁者」的头衔。虽然,是否仁慈,大家不得而知,但独裁确实是显然的了。

最大的独裁,是代码的管理权。因为作为创始人与核心开发者,他们往往以一己之力,贡献了绝大多数的代码,确定了项目最初的架构与发展方向。他们不会容忍任何人随意地向代码库提交代码。

在邮件列表中,一个新来的家伙,从没人认识,到能够独立的向代码库提交代码,非得经历艰辛的历程不可。这样的历程,简单的说,就是一次一次的 Code Review。被审核通过、合入代码库的patch越多,一个人对于社区的贡献就越大,可信度也越高,身份地位也逐步提高,然后,他也就可以去 Review其他人的代码了。

总结:在简陋的工具条件下,发展出高效、严格的社区协作模式

三、第二代开源协作模式

第二代开源协作模式,有两大特征:Web化、集成化。随着Web技术的不断成熟,开源社区也开始创造一个又一个的Web开源项目,其中Web化的项 目管理工具,如雨后春笋般冒了出来。在wikipedia上,issue-tracking systems列出了55个,project management software列出了152个,其中开源的也有30+,open-source software hosting列出了22个,堪称蔚为壮观。

这类平台又可以分为两大类:基于开源的项目管理工具或issue tracking工具,自建平台,以JIRA、DotProject、Redmine为代表;基于免费开源托管平台,以SourceForge、Google、LaunchPad为代表;

第二代的开源项目管理工具,可以说,主要是在向企业内的开发管理学习。文档、流程、角色、权限、统计报表等等功能,都开始出现了。有些开源项目,也在用这些东西。

以SourceForge与Google Code为代表的开源托管平台免除了开源项目搭建自己的官方网站,管理工具,代码仓库之类的繁琐事务,大大促进了开源项目的发展。不过,由于平台的功能总是受限的,因此自建门户,自组工具的开源项目依然层出不穷。

issue & milestone

在第二代开源协作模式日渐成熟的过程中,另一股潮流也正方兴未艾:「敏捷软件开发」。其中,最为深入人心的概念之一,就是每个迭代,完成一批User Story

在开源社区,这个概念被进一步演绎:无论是bug和feature,都被统称为issue。这些issue,被分到不同的milestone(版本),即使最后有可能延期,milestone也会定义一个预期完成时间。

这是好事?还是坏事?其实很难评价,因为从开源的原始教义而言:所有的贡献,都是自愿、随机、不可预期的。为自然生长的软件,规定里程碑,本来就显 得荒谬。但是,从另一方面而言,我们可以引用另一个中国人过马路的例子:「不管红绿灯,凑够一堆人就过马路」,开源软件,往往也是「不管里程碑,稳定一堆 特性和bugfix,就发布一个版本」。

如果在开源软件很少,更别提形成开源生态圈的情况下,这种随意的做法还是可行的。但是在大量软件,相互依赖的情况下,一个开源项目要赢得其他协作项目的信赖与协作,必须给出稳定的规划,以便相互配合。

这种规范,也是被逼出来的。

服务平台化

虽然黑客们喜欢写程序,但是要写的程序实在太多了,能够不重复造轮子,有现成的好工具可以直接拿来用,也是件好事。如果可以打开一个网站,注册一个用户,创建一个新的项目,剩下的事情自有平台帮忙打理,那么大家都可以愉快、专心的写自己的代码了。

平台在逐步进化,因而能够帮助开源项目,打理越来越多的事务。通常主流的开源项目托管平台,都能够完成:

  • 在线代码浏览,并能够支持不同的配置库
  • 需求管理、Bug管理,通常合并为Issue tracking
  • 版本与里程碑管理
  • 文档编写与管理,以Wiki的形式为主

更进一步的,还有能够完成:简单的自定义工作流、文件夹与静态资源管理、输出各种统计报表、甚至提供论坛、搜索、邮件列表以及各种排行榜等等。

在此之前,一个开源项目,是一个社区。到了大平台的时代,整个平台,构成了一个更大的社区。

总结:以Web形式提供的集成化开源项目托管平台,标志着开源项目的协作模式,进入成熟期

四、第三代开源协作模式

到了MySpace、Facebook与Twitter这样的SNS网站的兴起,开源项目的协作模式,受到SNS的启发,也随之进入了第三代,以 Social Coding为核心的开发协作模式,这样的模式在以Github为代表的网站上,体现的最为充分,众多的模仿者也层出不穷。过去的开源项目与托管平台,都 是以项目为中心来打造,而Github则是围绕着参与开源的人来打造。首先满足的不是项目的需求,而是个人的需求,由于对人的黏性大大增加,也使得 Github成为近年来最具吸引力的开发社区。

围绕着Github,一大批周边扩展服务被建立起来,构成了一个更加有活力的生态圈。而程序员们,不仅在Github上参与开源项目,更在Github上结交朋友,分享经验,增进能力。甚至这样的协作模式,还拓展到了编程领域之外,成为开放式协作的流行模式。

激励机制

第三代开源协作模式,以Github为代表,以Social Coding为精髓,这一代模式想要解决的问题,是激励机制的问题。

第一代开源协作,虽然创造了一批大大有名的项目,但事实上却是一个非常小圈子的事业。即使是最为成功的Linux内核开发,也不过1000~2000人。一旦人多事杂,就会出现管理混乱的现象。

第二代开源协作,虽然借鉴了很多企业界的规范管理经验,但是在事实上,却是不适应开源软件的风格的,举一个例子:在Redmine中存在的角色、权限、工作流之类的东西,实际开源项目使用的,却非常少。

第三代开源协作,借鉴了社交网络中的各种数值化模型,关注者数量,Star数量,Fork数量,Issue数量,Pull Request数量,都在显要位置标示出来,对于开发者形成正向激励,还有很多的统计图表,形象的展示了项目的活跃程度。

开源社区,原本就有非常深厚的,统计补丁数计算贡献度的传统,这一点在Github被发扬光大,可以说是优秀的继承与创新。

基于fork/pull request的协作机制

在github,一键就能够fork自己的分支,然后可以跟原有的分支毫无关联,也可以非常方便的提交pull request,这就带来了更加频繁的分裂,使得分裂常态化了。

原来的开源社区,开发者修改了代码,希望能够贡献给社区,需要穿越种种障碍,如果社区不接受,最后开发者只能逼不得已,自己开一个新的分支,变成一个新的项目。

在分裂是异常的状态下,分裂是罪恶的,是不应该的,是会带来阵痛的。当分裂变得常态化,pull request也变得常态化,分分合合,以每天N次的速度发生,恰恰因为如此,他不再是一种罪恶,而是一种健康的、向上的、以更快速度进步的模式。大家不 再是在一个版本下,各自贡献,而是在各自的版本下,独立发展,想分就分,想合就合。

Pull request,从一个代码合并的方式,变成了开发者之间主要的交流方式,他们发现,最好的交流,正是通过源代码来交流,一切的讲道理,都不如用源代码来讲道理。这恰恰是程序员们最习惯,也最喜欢的一种交流方式。

围绕Github出现的扩展服务

较之上一代的平台,Github提供了优秀的开放扩展机制:OAuth、API、SDK、WebHooks、ServiceHooks等等,使得围绕Github,扩展各种满足项目特定需要的服务,变得非常容易。

这就是从上一代平台的开源大社区,进化为「围绕Github的开源生态圈」。

到目前为止,Github一共支持超过170个不同的扩展服务,其中较为热门的服务有:

  • 与其他项目管理工具集成(Bugzilla,Asana, Basecamp,Redmine,JIRA,ZohoProject)
  • 与持续集成服务集成(Travis,Bamboo,CircleCI)
  • 与消息通知服务集成(Amazon SNS,Email,IRC,Jabber)
  • 与DevOps服务集成(AWS OpsWorks, DeployHQ)

Github 开放平台与API,基于Github OAuth API,其他网站可以支持开发者用自己Github账号登录,并使用一些有趣的服务。

  • Cloud IDE,用Github账号登录,直接在浏览器里打开一个IDE,编辑自己在Github上的开源代码
  • Resume Service,根据开发者在Github上的各种社交行为与开源项目贡献度,自动生成格式化的简历

这些扩展服务,极大的丰富了开源生态圈的内涵。

总结:社区天生就应该是社交化的,Social Coding与开源社区,简直就是天作之和。

五、开源协作模式的新探索

Git:作为标配

目前看来,git作为分布式配置库的王者地位,已经不可动摇了。能够初步总结的原因,至少有三个:

  • git与github互相促进,作为全球最大也最流行的开源社区,他的标配是git。这也导致越来越多的开源项目,选择git作为标配
  • 众人拾材火焰高,越是参与开发的人不断涌入,越是帮助git发展得更快。这是一个赢家通吃的世界
  • 开源生态圈的出现,使得围绕git、github发展出一大批相关的开源项目、开源工具以及次级社区。这一现象,在docker横空出世之后,再一次得到展现。

Code Review:必不可少

开源社区,一直有非常悠久的CodeReview的历史,哪怕在最早的mail & patch的时代,Review也是开源协作的头等大事。仅仅梳理Review的历程,也可以看到其中工具与流程的发展。

最初是邮件review,然后是在集成平台上内置review功能,或者提供更强大的review插件。到github创新的提出pull request,则是一种更加方便有效的review模式。

与此同时,独立于集成平台的专门的code review工具,也开始发展起来:Review Board、Google Gerrit、Facebook Phabricator是其中重要的几个代表。

Workflow:百花齐放

在git逐步流行之后,大家发现基于git可以选择的「玩法」实在是太多了。从最初写下一行代码,到最终出现在项目发布的版本之中,期间可以有无数的「路径」。

在git-scm.com官方教程《ProGit》里,提及了三种:集中式工作流、集成管理员工作流以及司令官与副官工作流。

在蒋鑫的《Git权威指南》里,又提及基于TopGit、基于submodule、基于subtree、基于repo、基于gerrit、以及git与svn配合使用的不同工作模型。

再后来:GitFlow、Github的Pull Request、以及基于Github的Github Flow等等工作模式,堪称百花齐放。

为什么会出来这么多workflow?因为团队与项目的差别,实在太大了。现在到我们简直无法想象:那些在各种情况下都坚持使用SVN都开发者,是怎么熬过来的?

当然,从另一方面来说:选择太多,也会带来另一种烦恼…

CI、CD、DevOps

从Everything as Code到Everything Automation,是另一个越来越明显的趋势。前两天,我从机场出来,正好看到两个并列的广告牌,一个广告的大意是:「UPS助您打通全球供应链」、 另一个则是「中国银行助您打通全球供应链」。这真的很有意思,看来在各行各业,大家都开始在关注整个生命周期的各个环节之间的打通。

只是,在软件领域,我们会感觉到这是一种回归。毕竟,最初的软件开发,都是很简单的。在一台计算机上,自己写程序,自己编译,自己调试、运行,最后发布。既不用依赖他人,更不用等待什么流程。

随着项目越来越复杂,参与的人越来越多,我们的软件,不能仅仅运行在自己的机器上,或者需要部署到服务器上,或者需要发布到某种平台上。在协作者众多的情况下,如何分工合作?
在开发者水平参差不齐的情况下,如何保证质量?在分工、协作、流程与质量保证的要求之下,如何提高效率?

这些都是DevOps致力于解决的问题,也是DevOps不断得以发展的原动力。

总结:开源社区,始终在进步,Github代表的也只是「一代」而已,新的一代协作模式,还会被创造出来的。

六、暗线:工具、习俗背后的逻辑

过去是如何?未来又会怎样?想要回答这类问题,其实需要更加深入的思考:「开源社区的协作模式,为何会变?变化背后的逻辑是什么?」

开源社区研发工具的两大目标:降低门槛,提高效率

开源社区,与普通的软件开发最大的不同,就是参与者多多益善。在《大教堂与集市》中,Eric Steven Raymond总结到:「如果开发者协调者有至少一个像Internet这样好的沟通媒介,并且知道如何不靠强制来领导,那么多人合作必然强于单兵作 战」,这简直就是绝妙的预言。虽然当年的ESR也许并未预测到,基于Internet会出现那么多辅助开源的相关工具(他们当时还只有邮件列表)。

所以,开源社区一直在致力于两个看上去相反的目标:「吸引尽可能多的人,以尽可能简单、便捷的方式,参与到开源中来」、「在人多得超乎想象的情况下,依然能够保持,甚至不断提高效率」。

如何计算参与者的贡献?

开源社区,不会给参与者发工资,因此激励是一个大问题。公平、公开、公正大计算所有参与者的贡献,以所有人都能够接受都形式,计算并公布各种排行 榜,可以说是开源社区特有都「刚性需求」,因此SNS与开源社区的结合,成为必然。以后,面向开源协作的大数据分析,也一定会出现。

如何激励、吸引、回报参与者?

计算参与者的贡献,仅仅是公平激励的基础。让激励变得有趣,变得有价值,变得有意义,则是吸引与回报参与者的不二法门。因此:游戏化的思路,会被越来越多的引入到开源社区中来。

如何保障项目质量?

开源项目保障项目质量都最大利器,是引入数量众多都热心测试者。但是,仅仅有人愿意测试,主动、积极都帮助测试,已经越来越不够了。随着项目越来越复杂,开源项目必须逐步走出仅仅依赖肉眼、依赖人多+运气的质量保障模式。

自动化测试、以及更加规范的Review流程,则是必然出现,而且将越来越重要的环节之一。

如何协调一致的工作?

自由与规范,计划与变化,兴趣与责任。经常会在社区里,成为争论的热点话题。虽然在《大教堂与集市》中,ESR极力鼓吹「礼物文化远远胜过交换经济」,但是:「在一个庞大的社区,各种各样的事务都需要有人去完成,而且还不能漫无章法。」

因此:「某种调节手段、协调者与协调机制、甚至是看不见的手」之类的东西,会慢慢的回到社区

如何在社区里平等、高效的协商?

目前来说,依然只能是线上讨论+线下开会。虽然,很多开源社区,开始学习《罗伯特议事规则》这样的开会圣经。但是,开会依然是最令程序员感到苦恼的事情。在这方面,将来会不会出现更好的辅助工具,这方面很值得期待。

结束语

唯有变化,是不变的。开源协作模式,同样如此。惟愿我们,能够成为推起其前进的力量之一。

转、进、定——我的2014

看着很多朋友,都纷纷在总结回顾自己的2014,我也试着总结一下吧,原本想按照往年的传统,选一个年度汉字的,结果思前想后,发现至少需要三个字,才能表达这一年的林林总总。

一、转:这一年我有三大转变:

  • 加入华为,而且干满一年了;
  • 开始跑步,而且喜欢上跑步了(不是坚持,就是喜欢);
  • 彻底离开知乎,而且真的戒掉了;

二、进:这是我进步非常大的一年,因为在华为的工作与开源有关、与研发有关,我思考了很多、很多,也有了很多的收获。

在多年以后,也许会有人评价,2014年是华为的开源元年,而我们则是这一重大变革的亲历者。

从这个意义上来说,我感到非常自豪。

三、定:从而立到不惑,慢慢的就能定下来了

40不惑,无非是心有定见,眼看马上就要39了,我仔细思索了一下自己的心路历程,渐渐的感到:自己的想法,已经很少左右摇摆,虽然心态依然开放,但判断却很少犹豫,这大概就是一种不惑吧。

最后,祝愿所有的朋友,新年快乐,万事如意!身体健康,阖家幸福!

再也回不去的那三年

离开创新院,已经2年了。至今我还记得,老郭与我谈话,告知我被公司「Fire」时,是2012年的平安夜。我百感交集,又故作轻松的与朋友聊天:「哈哈,真是不错的圣诞礼物啊!这回还赔了不少呢!」事实上,哪怕有一线可能,我也是绝不想离开创新院的。在创新院的三年,是我的职业生涯中,最愉快、也最难忘的三年。只可惜,那是再也回不去的三年了。

刚刚离开创新院的时候,固然是内心愤懑不平,对盛大也有很多私下的批评。但是,在后来的日子里,我倒是越来越怀念盛大,越来越怀念创新院的氛围,也越来越能够以平常心,看待那三年里的是是非非了。

一、那些美梦成真的日子

在很多人的职场梦想中,大概都有这么几条吧:轻松但却有趣的工作;投缘而又能干的同事;再加上各种贴心服务的工作场所;以及拿到足够体面的薪资。在创新院的那三年,我们大多都是在过着这样的日子。
每周一次的分享会,各种各样的牛人会跟大家分享新鲜的观点以及有趣的经验。台下坐着一群兴致勃勃的同事,一场分享会往往开得热火朝天,大家吵得天翻地覆。后来,我们经常会把分享会,称之为「拍砖会」,因为非此不足以形容其激烈程度。
当然,另一个令我自豪的成就是:「我在创新院,人称砖王」。被我拍过的同事简直数不清,可以说犯下了「累累血案」!更加有意思的是:2010年的创新院年会,公司竟然给我发了一块金砖,正式册封我为「砖王」,只可惜那块金砖是巧克力做的,哈哈!
拍人者也常被人拍。别看我在外面的技术分享,也常常被人以为是技术大牛。他们是不知道我在创新院里,被人拍得有多惨。我至今还记得,被老莫拍过关于NoSQL的技术演讲;被Hax和Tinyfool拍过关于开源的技术演讲;被Neo拍过关于开放平台的技术演讲。那些拍人与被拍的经历,都令我获益良多。
在创新院,我与很多人成为了朋友。我们常常会打一杯免费咖啡,找一个舒服的沙发,然后坐下来随意的聊一些有趣的话题。我还记得第一次和tinyfool聊天,是关于中医的,他是一个坚定的中医黑,而是我一个不太坚定的中医粉。我还记得第一次和Felix Ding聊天,是因为我们都非常喜欢村上春树的小说。我还记得第一次和橙子聊天,是因为他的桌子上堆满了大大小小的魔方。我还记得和老许有一次非常深入的聊天,是我以盛大今日的记者身份,对他进行采访。
09年~10年的创新院,弥漫着一种创业的氛围,我们在一起聊得最多的,是新技术、新模式、新应用、新机会。几个投缘的朋友,聊得深入透彻之后,就开始准备材料,去上计委会,看看能不能获得立项的机会。
美好的回忆实在太多,但是,我必须转入下一节了。

二、那些Bambook的前尘往事

我和老范都是铁杆的网络小说迷,在进盛大之前很多年,我们就已经是起点的高V了。自从知道创新院里有一个电子书项目之后,我们就一直非常关注,经常回到楼上去找他们那帮兄弟闲聊。
再后来,电子书正式发售,我和老范又作为高级帮闲,每周旁听他们的运营例会。而且时不时的会忍不住发表自己的各种意见。
再后来,搞Bambook开发大赛,我、老范、雪愚、winter、周劲羽等很多很多人,都参与其中。盛大当时也财大气粗,花了100万来搞一个比赛。我们一群人也相当的尽心尽力,算是将这个比赛做得皆大欢喜了。事后有一个朋友,在跟我聊天的时候,还谈起这次比赛,他说:「现在看来,你们盛大对开发者,还是很靠谱的。」我听到这样的评价,真是极为自豪。
再后来,大年不再主管Bambook,来了新的CEO。公司开始反思电子书在生产与推广过程中的「大手大脚」,压缩成本,缩减预算。原本计划中的Bambook开发者大会,Bambook第二届、第三届大赛,Bambook开放平台的后续计划,全都被砍掉了。
再后来,我们淡出了Bambook团队,陆陆续续听到了各种各样的坏消息,最后在一个月前,我听说Bambook已经彻底Over了,团队的人也全部走光了。
这是一个曾经聚集了非常多牛人的优秀团队。这是一个曾经生产出了比Kindle好得多的电子书的果壳电子。这是一个曾经有着良好口碑与开发者忠诚度的开放平台。却被一个又一个愚蠢的高层决策,最终废掉!

三、那些盛大云的前尘往事

老许、老季、老何,都是让人树大拇指的大牛。他们都曾经是盛大云计算的掌舵人。离开盛大之后,这几位依然混得风生水起。但是,令人费解的是:在盛大,他们就是没做成事。这不禁令人想到了橘生淮南与淮北的典故。
最可惜的,还要数老何,因为当年的盛大云,在他的带领下,一度红红火火,牢牢占据国内云计算厂商的第一梯队。虽然盛大云和阿里云都有无数的人在骂,但似乎骂盛大云的人,还略少一些。在云计算这个领域,盛大曾经是大有希望的。
再后来,盛大云战略转型,开始专注于服务内部,特别是服务于酷六那个扶不起的阿斗。
再后来,盛大云就从大家的视线中消失了。
作为一篇回忆创新院的文章,的确不该在盛大云这边着墨太多,就此打住吧。

四、所谓战略家

此处删去500字

五、孵化器与御林军

还是回到创新院的主题上来吧,在我看来,创新院从创立之初,就存在着隐患。最大的矛盾,在于桥哥和大年,对于创新院的看法不同。虽然大年是创新院的院长,但是桥哥才是真正决定创新院生死的人。
大年是一个非常理想主义的人,而且常常有很多奇思妙想,创新院就是他的理想国,也是我们这些人的乌托邦。曾经在某一次会议上,我随口说了一个设想,大年当场就大为赞赏。我也没有特别在意,谁知道,后来大年还为此特别奖励了我一万元,就为了一个点子,而且还是一个尚未实现的点子。
在刚刚离开盛大的日子里,我曾经愤愤不平的对朋友说过:「大年建了一个游乐场,我们以为是进来玩的,没想到我们是进来被玩的。」到现在,平心而论,我们应该说:「大年是真心实意的,找我们来一起陪他玩的。」
但是,桥哥的想法大不一样。他并不是在招揽志同道合的同伴。正如盛大集团官网首页的桥哥题词:「最高的工资给最优秀的人才,最优秀的人才创造最大的价值」。一种老板雇佣打工仔的心态,表露无遗。
在桥哥的眼中,创新院就是他的御林军,要「召之即来,来之能战,战之能胜」。如果不能作为国际级大牛为桥哥装点门面,就必须为集团创造价值。在内部,我们知道,桥哥是可以从创新院收税的。只是,大家从来不清楚,收税的比例是多少?
随着创新院的大多数项目,轰轰烈烈,热热闹闹,却乏善可陈。集团收税的比例,就越来越高,越来越多的人,被拉出去支援别的项目,别的业务,别的公司。最夸张的一次抽调,就是全集团共同支援酷六那回。前前后后,只怕投入了有几百个人年的力量。
我曾经有一次跟老郭打电话,痛陈「帮忙的坏处」,我对老郭说:「你把他们招进来,是让他们进来实现梦想的,是让他们来创业的,现在他们都被拉出去帮忙了。那么咱们这个创新院,当初的初衷又到哪里去了呢?」
现在想来,老郭又何尝不知道这些,不过他也无能为力罢了。因为不能通过创新,证明创新院的价值,再不通过输出技术支援证明价值,创新院的就要被干掉了。

六、「为什么盛大创新院多方出击,但真正给力的产品不多?」

这是2011年,知乎上的一个问题。我当时还在创新院,自然不能有太多的批评,兼之又不愿匿名答题,所以就写了一个放之四海而皆准的回答,大意是:「创新本来就难,慢热的创新尤其需要等待,一项创新,在他刚刚诞生的时候,很可能是一点都不酷,一点都不给力的。」
当时hax就给我留言:「老庄,应该匿名再答一个。」时隔三年之后,我打算再回答一下这个问题。
有些话,我当时的确没说错,一个非常确凿的证据,是wifi万能钥匙。当时在创新院立项的时候,几乎没有人看好,在分享会和计委会上面,他们都被拍得很惨。包括我当年,也是绝对不看好的。记得当初还跟张发有激烈的争论了很久。真的万万没想到,这个产品,现在会发展得这么好!
霍炬说:「创新院乃至盛大后来出现的问题,并不在创新院本身,更不在老郭或者大年。甚至说问题在于盛大集团,或者问题在于陈天桥,我觉得都算不上公平。」我是不能同意的,在我看来:作为一场「共业」,身在其中的每一个人,都有责任。从最上面的桥哥,到大年,到老郭,到我们这些普通的创新院的每一个成员,全都有不可推卸的责任。
下面开始正面回答问题:
在我看来,创新院的最终失败。主要有内外两个方面的原因。
主要外因,是集团对待创新院的态度与政策,存在摇摆与短视。或人才储备,或装点门面,或随时抽税,或弃若蔽履。
内因又可以分开N条来说:
其一:过于宽松,缺少紧迫感。对于创新,宽松当然就够了。若要创业,一定得有紧迫感。在创新院有一项令人感动的政策:「大年说过,只要创始人不放弃,我们就一定不放弃」。简直是超感人的理想主义。但是,对于身在其中的我们而言,那就是只有胡萝卜,没有大棒了。
其二:人才结构不合理,全是高手,而且大多数都是技术方面的高手,没有中手、低手。更缺乏设计、产品、运营、市场的人员。整个创新院,几百个高手,牛人,全都想自己立项,到后来也立了无数的项目。每个项目,都只有创始人,都严重缺人。想要找一些能够干杂事的人手,领导说了:我们创新院不能招这种太低端的人才。
其三:管理架构不合理,明明想要做一个孵化器,却没有必要的孵化机制,配套设施,培养与辅导机制。一个巨大的扁平化的架构,上百个团队,几乎所有的事情都需要直接找老郭汇报。就算老郭是铁人+超人,也不可能同时处理好这么多事情。
这些原因,导致的结果就是:创新项目一大堆,每一个项目都缺胳膊少腿,往往努力而不得其法,不得其人。更有甚者,混日子也混得不错。

七、结束语

当年我曾经写过一段话:创新院作为一个真人MMORPG,就是大老板出钱,让二老板玩的一个游戏。其他人都是来陪玩的。大老板没钱以后,这个游戏就没法继续玩下去了。
现在看来,实在是过于激愤了些,现修正如下:创新院是一个极度理想主义与极度现实主义无法调和后的一场悲剧。作为悲剧中人,我们都曾经做过一场美梦,只是梦醒之后,大家都再也回不去了!

ps:关于盛大的开源往事,以及盛大的经验值体系,我曾经另外写过两篇文章,这篇文章里就不再扯到了。

企业开源杂谈

良法美意的命运——聊聊盛大的经验值

写给知乎:最艰难的告别

这一周,我的工作量很大。因为,我下决心要告别知乎了。为了让自己绝对不可能再回来,我做了以下一些事情:

  • 关注的80+话题,一一取消关注
  • 关注的50+专栏,一一取消关注
  • 关注了880+知友,一一取消关注,就像是向880+朋友,一一道别
  • 收到了2000+个邀请,积压着一直没有回答,也只能一一忽略,抱歉
  • 关注了3000+问题,一一取消关注,这样我就不会看到自己关心的问题的最新回答了
  • 回答了1200+问题,一一看过,有价值的移到自己的blog,然后全部删除,有时候还要再回顾一下评论
  • 写了110+篇专栏,一一看过,转移,删除
  • 卸载了手机上的知乎

这些事情,花了我7~8天的时间。写完这篇专栏之后,我会把知乎的密码改成一个自己永远都想不起来的乱码,以确保自己再也上不了知乎。

 

来知乎已经四年了,我也曾经说过:「说了这么多,但是,我从来没有想过,要戒知乎!知乎依然是我现在最喜欢,也最经常去的网络社区(没有之一)。」

为什么要这么干呢?因为对知乎,彻底失望了。事情的来龙去脉,可以看这几篇文章:

一篇锤子手机总监级别的软文是怎样诞生的?

[知乎专栏–思考IT]运营的底线

[知乎专栏–私吐槽]是什么人,在修改问题?

[知乎专栏–私吐槽]知乎,你们这样真的有意思吗?!!

如何看待『Smartisan OS 中的定时静音功能』问题下出现的许多知乎用户认为是软文的现象?

这个问题里的黄继新的回答!

Smartisan OS 中的定时静音功能设计过程是如何的?

以及这个问题的修改记录里,众多知乎员工的身影!

 

既然想走,那就走得彻底些,最后的最后,我的心情非常复杂,却不想写什么狠话。2年前,我曾经为知乎写过一首诗,就以这首诗,作为这段时光的结束吧。

 

对酒当歌,叹人生兮几何。
古有屈原,咏天问与九歌。
浩瀚苍茫,当上下而求索。
时光荏苒,惜岁月之蹉跎。

昔日艰难,有凿壁而偷光。
发奋苦读,常刺股与悬梁。
名师难遇,千里求学他乡。
知音难觅,伯牙摔琴心伤。

今非昔比,求知易如反掌。
身无长物,揽万卷于网上。
问答辩难,可教学而相长。
千里知音,未谋面却来访。

知乎出世,聚英才于一堂。
稀有社区,以认真为风尚。
妙问妙答,常有缘得欣赏。
牛人高人,可讨教也无妨。

赞曰:
惟愿知乎常驻世,惟愿知友常交流;
惟愿知识常流传,惟愿智慧常增长。

无觅相关文章插件,快速提升流量