Comments (0)

By qyjohn, December 3, 2013 10:28 pm

I read, with great interest, all the media reports and commentaries regarding Amazon’s ambitious plan to deliver packages with unmanned aviation vehicles (UAV). In the early days of my career, I was exposed to some of the core UAV technologies such as IMU (inertial measurement unit), autonomous guidance and navigation,  as well as collision avoidance. I have also the experience of building my own UAV with Sun SPOT – an embedded wireless sensor network (WSN) platform developed by Sun Microsystems five years ago – as the central control unit and FreeWave TDMA modem as the datalink. With all the advancements in WSN, IOT and UAV, I tend to believe that the technology to fly the package to the customer’s back yard has already been there, or needs only very little ruggedization and refinement.

In my point of view, the biggest challenge behind Amazon Prime Air is to ensure the security of the UAV itself, which can be further categorized as anti-hijacking and collision avoidance.

Hijacking a UAV might sound impossible at a first glance, but was done at least once. On December 4 2011, an American Lockheed Martin RQ-170 UAV, operated by the Central Intelligence Agency, was hijacked and brought down by an Iranian cyber warfare unit. I am not an expert on hijacking UAV’s but I can can think of at least the following approaches:

• Datalink Repression – It is almost certain that the UAV has been designed with the ability to accept and execute navigation and control commands on the fly. In this case, commercial carrier networks (such as AT&T, T-Mobile) seem to be the most convenient (and economically feasible) way to provide the datalink between Amazon and the UAV. In other words, the network being used to transmit guidance, navigation and control (GNC) commands for the UAV’s might be the very same network on which people surf the Internet, which is vulnerable to hacker sniffing and attacks. For example, radio repression technologies might be used to cut off the connection between the UAV and the command center, which can pave the road for further malicious attacks.

• GNC Injection – Assuming that a malicious group had access to some UAV’s (with brute force such as gun shots), it might not be long for them to reverse engineer the UAV to unveil the underlying GNC protocol. All in a sudden, the whole Amazon fleet is under the control of one (or even more then one) malicious group lurking somewhere waiting for a perfect timing to change the course of the UAV’s via GNC injection. Can’t believe this? UAV’s are computers too, and are vulnerable to virus and human attacks. Remember, NSA infected 50,000 computer networks with malicious software, and so can other malicious groups.

• Location Spoofing – The Amazon UAV’s might be using GPS as the primary positioning technique, and each UAV might have a built-in GPS coordinate as its home address. In this case, GPS spoofing might be employed to make the UAV believed that it has arrived at the desired location, and landed in the hands of a malicious group. Therefore, additional technologies such as IMU or WSN should be employed to improve the credibility of the sensed / calculated position of the UAV’s.

Collision might not be a problem if Amazon was the only business to obtain a license to operate UAV’s for civilian applications. This is very unlikely because FedEx had already expressed similar interests, and there are already a wide range of UAV applications waiting for the approval of FAA. When the number of UAV’s increases, the possibility of UAV collision also increases.

For commercial airlines, they fly on pre-designated air ways with pre-determined schedules. There is a global effort trying to keep track of all the airplanes, and prevent them from crashing into each other. On June 30, 1956 two airplanes collided over Grand Canyon with over 100 fatalities. A Wikipedia page on mid-air collision lists 48 civilian mid-air collisions during 1922~2012, with a total number of 2884 fatalities.

For civilian UAV’s, the air way network will be a lot more complicated as compared to the commercial airline network. Each and every home address now becomes a potential “airport”, and each UAV flight has a unique destination which can’t be planned months ahead. New routing algorithms, as well as collision avoidance protocols, will be needed to facilitate these UAV flights.

Comments (3)

By qyjohn, October 3, 2013 9:16 pm

本文是对《CY13-Q2 OpenStack, OpenNebula，Eucalyptus，CloudStack社区活跃度比较》一文的补充和更新。对本文内容感兴趣的读者，可以通过电子邮件或者新浪微博（@qyjohn_）与我联系。

本文同时发布了一个英文版本，可以参见CY13-Q3 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack这个帖子。

需要说明的是，这个社区活跃度比较项目起源于CY11-Q4，此篇报告是到目前为止已经发布的第八个季度性的报告。尽管作者于2012年10月至2013年7 月间曾短暂地就职于Eucalyptus公司，但是本文中所表达之观点完全是作者本人的观点，而非作者目前或以前所在公司的观点。

本文的目的是通过论坛和邮件列表的原始数据对OpenStack、OpenNebula、Eucalyptus和CloudStack项目的社区活跃度进 行分析和比较。主要的原始数据是自2009年来这四个项目的官方论坛和邮件列表每个月所产生的讨论主题数、帖子数、以及参与讨论的总人数（邮件地址或者用 户账号）。为了获取这些数据，我写了一个Java程 序自动地从这四个项目的网站下载了所有的论坛和邮件列表信息，并且从这些信息中分析提取出我所需要的数据。程序提取的数据被导入MySQL数据库中以便进 行统计分析，统计分析的结果通过LibreOffice生成分析图表。

从CY13-Q2开始，OpenStack项目启动了一个名为Ask.OpenStack的论坛，我们已经将这个论坛的数据添加到此次分析的数据源当中。值得注意的是，来自Ask.OpenStack的用户和OpenStack其他社区的用户有较大的重合。在此CY13-Q3分析报告中，我们采取了一些初步措施来处理用户重复计数的情况，但是目前尚不能完全避免同一用户重复计数的问题。

此外，Apache CloudStack项目从孵化器毕业，其邮件列表的名称发生了变化，但是其内容和用户基本不变。值得注意的是，原来在incubator-cloudstack-dev邮件列表中有大量由JIRA自动生成的邮件内容，类似的内容在cloudstack-dev邮件列表中大大减少了。不过我们依然保留了以前的过滤器设置，自动地排除了所有标题中含有”[jira]“标识符的信息。

图1 和图2分别是如上所述四个项目每个月所产生的讨论主题数和帖子数。可以看出：

(1) 在过去12个月中，与OpenStack和CloudStack相关的讨论数量在同一水平上，与Eucalyptus和OpenNebula相关的讨论数量在同一水平上；

(2) 在过去12个月中，与OpenStack和CloudStack相关的讨论数量远大于与Eucalyptus和OpenNebula相关的讨论数量。

通常来讲，一个讨论主题得到的回复数越多，表明该主题的讨论越深入。一个论坛或者邮件列表如果只有主帖而没有回复，说明这个社区的参与程度很低。因此，平 均意义上的“讨论帖子数/讨论主题数”则反映了一个社区的参与程度，这里我们暂且称之为参与度（Participation Ratio）。

由图3 可以看出，在过去12个月中CloudStack和Eucalyptus项目的参与度相对较高高，接近于4；OpenStack与OpenNebula项目的参与度相对较低，接近于2。

我们也注意到参与度这个概念引起了一些争议。有些人认为“讨论帖子数/讨论主题数”较低象征着某个社区具有快速解决问题的能力，社区成员所提出的问题能够在很短时间内得到解答，因此不需要多个帖子来解决一个问题。有些人认为“讨论帖子数/讨论主题数”较高可能意味着某个社区可能出现了争论，而这种争论可能已经偏离了某个社区的讨论方向和范围。无论如何，参与度这个名称的确反映了我们的某些主观看法，在一定程度上削弱了本报告的客观性。由于我们暂时没有找到一个更加合适的替代名称，在这个报告里面还是延用原来的名称（欢迎各位读者贡献更好的参数名称）。

图4 所示为这四个项目每个月参与论坛或者邮件列表讨论的总人数。可以看出，OpenStack项目的活跃用户数量要远大于其他三个项目。CloudStack项目的活跃用户数量也明显大于OpenNebula和Eucalyptus。在过去12个月中，CloudStack和OpenStack项目的活跃用户数量都在稳步攀升，而Eucalyptus和OpenNebula项目的活跃用户数量基本上没有增长。

值得一提的是，虽然CloudStack的活跃用户数量稍微小于OpenStack，这两个项目的主题和帖子数量是基本相当的（参见图1和图2）。

累计社区人口（简称社区人口）指的是曾经通过论坛或者邮件列表参与过讨论的用户和开发者总数。（不包括在论坛或者邮件列表中注册但是从未公开参与讨论的社 区成员。）这些人或多或少地使用过相关产品，但是并不代表他们目前还是活跃用户。图5 所示为这四个项目的社区人口增长趋势。可以看出，OpenStack与Eucalyptus项目的社区人口遥遥领先，CloudStack与OpenNebula项目的社区人口相对较低。

问题在于，开源IaaS软件经过这么多年的发展，长期累计社区人口的意义已经越来越弱。一方面，某些早期用户可能已经多次改变了阵营；另一方面，某些早期论坛和邮件列表已经结束了历史使命。从社区活跃度的角度来看，我们认为最近6 个月或者最近12个月的累计社区人口可能是有意义的，但是将累计社区人口无限制地延伸到侏罗纪时代，可能会使这个参数失去实用价值。

图6 所示为这四个项目每个月新增加的社区人口数量。在过去六个月中，CloudStack与OpenStack的社区人口增长速度基本相当。

与CloudStack和OpenStack向比较，Eucalyptus和OpenNebula的社区人口增长较为缓慢。

图7 是图4 与图6的重新组合。其中，实线部分表示的是每个月参与论坛或者邮件列表讨论的人数，虚线部分表示的是每个月新加入论坛或者邮件列表的人数。

在过去12个月中，OpenStack与CloudStack项目的新增人口占当月活跃用户的30%左右，OpenNebula与Eucalyptus项目大概是50%。如 果不考虑社区人口的规模的话，可以认为OpenStack与CloudStack社区的粘性大于OpenNebula与Eucalyptus社区。

图8 所示分别是本文所述四个项目的社区人口，过去一个季度的活跃用户数量，以及过去一个月的活跃用户数量。可以看出：

(1) OpenStack的社区人口最多，然后是Eucalyptus、CloudStack、OpenNebula；

(2) 在过去一个季度中，OpenStack的活跃人口最多，然后是CloudStack、Eucalyptus、OpenNebula；

(3) 在过去一个月份中，OpenStack的活跃人口最多，然后是CloudStack、Eucalyptus、OpenNebula。

我们还计算了本季度活跃人口与累计社区人口的比值。对OpenStack项目来说，这个比值是36.3%；对于CloudStack项目来说，这个比值是24.2%；对于OpenNebula项目来说，这个比值是11.8%；对于Eucalyptus项目来说，这个比值是4.3%。很显然，相当部分的OpenStack和CloudStack社区成员选择了留下，而大部分的Eucalyptus社区成员选择了离开。这与我们在图7 中所观察到的现象（OpenStack与CloudStack社区的粘性大于OpenNebula与Eucalyptus社区）是一致的。

在CY12-Q3分析中，我们首次提出了“社区活跃度指数”这样一个参数。从CY13-Q3开始，这个参数修改为如下几个参数的组合：

(1) 本季度帖子总数，代表相关讨论的规模；

(2) 本季度参与度，代表每个问题获得的回帖数量；

(3) 本季度活跃用户，代表从社区获得帮助的可能性（长期）。

在这个分析中，我们选择如上各个社区的平均值作为参考数据，并将每个社区的数据与参考数据进行比较。我们将每个社区各个参数与平均值的比值之和称为“社区活跃度指数”。可以认为，社区活跃度指数最高的项目，是最活跃的项目。

从图9 中可以看出，目前OpenStack项目的“社区活跃度指数”最高（以明显的优势领先），然后是CloudStack、Eucalyptus、 OpenNebula。

曾经有多位读者建议我们基于Git活动对各个主流的开源IaaS项目的开发情况进行分析。我们注意到CloudStack、Eucalyptus、OpenNebula以及OpenStack项目都使用git进行版本管理。因此，我们基于来自git的日志数据对这几个项目的开发情况进行了一些简单的分析。需要指出的是，对于OpenStack项目来说，其数据源包括了托管在github.com上的openstack项目（包含57个子项目）和openstack-infra项目（包含33个子项目）。

在CY13-Q1报告中，我们使用了git log这个命令获取日志数据。从CY13-Q2起，我们将使用git log –no-merges这个命令获取日志数据。

图10所示分别是本文所述四个项目每个月进行提交（commit）操作的次数。总体来看，OpenStack项目提交代码的频率远远超过其他三个项目。这是由于OpenStack项目的数据源一共包含了90个子项目。CloudStack项目提交代码的频率也明显高于Eucalyptus和OpenNebula。与OpenNebula项目相比较，Eucalyptus项目提交代码的频率也不低，但是存在较大的波动情况，具有比较明显的批量更新的特征。OpenNebula项目提交代码的频率较低，平均每个月提交代码200次左右。

图11所示分别是OpenStack项目中各个子项目目每个月提交代码的次数。总体来看，Nova子项目提交代码的频率较高，是其他几个子项目的三倍左右。值得注意的是，尽管各个子项目提交代码的频率各不相同，但是其时程曲线基本上是一致的，波峰和波谷基本上出现在相同的时间。这个现象表明尽管OpenStack项目中各个子项目相对独立，但是具有相同或者相似的开发计划和开发进度。可以认为，OpenStack项目在子项目的管理和协调方面是做得比较好的。

图12所示分别是本文所述四个项目每个月提交代码的人数。总体来看，OpenStack项目提交代码的人数远远超过其他三个项目，并且一直保持迅猛增长的势头。CloudStack项目提交代码的人数也有所增长，但是其增长速度较为缓慢。Eucalyptus项目和OpenNebula项目提交代码的人数相对较少，并且在过去12个月当中基本上没有增长。

图13所示分别是OpenStack项目中各个子项目每个月提交代码的人数。总体来看，Nova子项目提交代码的人数较多，是其他几个子项目的三倍左右。

人们通常通过代码贡献者所使用的电子邮件地址来识别其所在的机构。尽管这种方式存在较大的缺陷（例如有一些机构鼓励雇员以个人的名义向开源项目贡献代码），但是还是可以从某种程度上揭示不同机构对某个开源项目的贡献力度。图14所示分别是每个月向本文所述四个项目提交代码（commit操作）的邮件地址所属域名数量。总体来看，OpenStack项目提交代码的域名数量远远超过其他三个项目，并且一直保持迅猛增长的势头。CloudStack项目提交代码的域名数量也有所增长，但是其增长速度较为缓慢。Eucalyptus项目和OpenNebula项目提交代码的域名数量相对较少，并且在过去12个月当中基本上没有增长。

图15所示分别是OpenStack项目中各个子项目每个月提交代码（commit操作）的域名数量。总体来看，Nova子项目提交代码的域名数量较多，是其他几个子项目的三倍左右。

下面这个表格以电子邮件所属域名的形式列出了在CY13-Q3期间向CloudStack、Eucalyptus、OpenNebula和OpenStack项目贡献代码次数最多的机构（以及贡献代码次数的百分比）。可以看出，Eucalyptus和OpenNebula属于以单一机构为主导的开源项目，而CloudStack和OpenStack属于由多家机构共同合作的开源项目。对于CloudStack项目来说，来自Citrix的影响依然非常明显，直接来自citrix.com和cloud.com的邮件地址占了48%（与CY13-Q2相比较降低了3%）。对于OpenStack项目来说，来自RedHat的贡献占了15%，来自IBM的贡献占了11%，来自HP的贡献占了5%，来自Mirantis和Rackspace的贡献各占了4%。

下面这个表格以电子邮件所属域名的形式列出了在CY13-Q2期间向OpenStack项目各个子项目贡献代码最多的机构（以及贡献代码次数的百分比）。值得一提的是，程辉所创建的UnitedStack几乎在所有的子项目中都有突出的贡献，杜玉杰所在的九洲云对Glance项目的贡献也较为突出（九洲云在CY13-Q2中对Keystone项目有突出贡献）。此外，我们注意到Intel公司也开始向OpenStack贡献代码。我们知道Intel公司自从OpenStack项目创建之初就表示大力支持OpenStack项目。以前Intel公司内部试图在OpenStack的一个早期版本的基础上打造一个Intel自己的OpenStack发行版，并导致了Intel自己的OpenStack版本与OpenStack主干不相兼容的情况。显然，Intel公司已经意识到更好的选择是直接加入OpenStack主干的开发，而不是关起门来在家里自己搞一个发行版。

与本文相关的PDF版本幻灯片可以从这里下载。如果您需要重新分发本文内容，敬请您保留相关作者信息。

Comments (3)

By qyjohn, October 3, 2013 8:34 pm

This article is an update version of my previous article CY13-Q2 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack. Readers who are intested in further discussions please contact me via email at the above-mentioned address.

A Chinese version of this article is published at the same time, which can be found at CY13-Q3 OpenStack, OpenNebula, Eucalyptus, CloudStack社区活跃度比较.

It should be noted that this community analysis project was initiated in CY11-Q4, and this particular report is the 8th quarterly report being published since. The author served shortly as the Director of Customer Success in China for Eucalyptus Systems Inc during October 2012 and July 2013. However, the opinion presented in this report belongs strictly to the author rather than any current or previous employer of the author.

The objective of this article is to compare the OpenStack, OpenNebula, Eucalytpus and CloudStack user and developer communities, base on the communications between community members in the form of mailing lists or pubic forum discussions. The data being discussed include the total number of topics (threads), messages (posts), and participants (unique email addresses or registered members). To obtain the above-mentioned data, a Java program was written to retrieve all the forum posts and mailing list messages into a MySQL database for further processing. The analysis results were presented in the form of graphs generated by LibreOffice.

Starting from CY13-Q2, the OpenStack project kicked off the Ask.OpenStack discussing forum, which is now included as a data source for this analysis. It should be noted that there exists significant membership overlap between Ask.OpenStack and other OpenStack mailing lists and forums. In this CY13-Q3 report we carried out some preliminary de-duplication efforts for this data source, but certain amount of double counting still exists.

The Apache CloudStack graduated from the Apache incubator in CY13-Q2. The names of their mailing lists changed a little bit, but the membership and discussion scope remained the same. It should be noted that before this change there were a significant amount of message in the incubator-cloudstack-dev mailing list that were auto-generated by JIRA. Such messages became a lot less in the  new cloudstack-dev mailing list. However, we still keep our previous filtering settings, which excludes any messages with “[jira]” in their topic.

Figure 1 and 2 represent the monthly number of topics (threads) and posts (messages). It can be seen that

(1) During the past 12 months, OpenStack-related discussions and CloudStack-related discussions were approximately on the same level, while Eucalyptus-related discussions and OpenNebula-related discussions were approximately on the same level.

(2) During the past 12 months, the volume of OpenStack and CloudStack related discussions were much higher than that of Eucalyptus and OpenNebula.

Generally speaking, the number of replies to a specific topic represents the attention being received, and the depth of discussion for that particular topic. When the number of master posts (the original post that started a particular topic) is more than the number of replies, it is safe to conclude that the participation of the forum or mailing list is very low. Therefore, the ratio between “the number of  posts” and “the number of topics” represents the participation rate of an online community. In this study we call this ratio the Participation Ratio.

As can be seen from Figure 3, during the past 12 months the participation ratios of CloudStack and Eucalyptus were relatively higher, which were close to 4;  the participation ratios of OpenStack and OpenNebula were relatively lower, which were a little bit higher than to 2.

We do notice that the concept of “participation ratio” generated some disagreements. Some people think that a lower “post-to-thread ratio” represents the ability to resolve problems in a very short time, therefore only a very limited number of discussions are needed. Some people think that a higher “post-to-thread ratio” might be an indicator that the community are on flame, and during a flame a large portion of the posts might be off-topic. Anyway, we agree that when we call this parameter “participation ratio” it somewhat represents our own opinion and it undermines the objectiveness of this report. However, because we do not find a better name to represent this parameter, we will just use it for the time being. (Dear readers, you are more than welcome to contribute a better name for this parameter.)

Figure 4 shows the number of monthly participants of the four projects being discussed. It can be seen that the number of active participants of OpenStack is much higher than the other three projects. The number of active participants of CloudStack is also significantly higher than OpenNebula and Eucalyptus. During the past 12 months, the number of active participants for OpenStack and CloudStack were growing steadily, while the number of active participants for Eucalyptus and OpenNebula exhibited no significant growth.

It should be noted that although the number of active participants of the CloudStack project is somewhat smaller than that of the OpenStack project, both projects have approximately the same amount of discussions (as shown in Figure 1 and Figure 2).

Accumulated Community Population refers to the total number of users and developers who have participated in forum or mailing list discussions. (This number does not include those who have registered into discussion forums or mailing lists but have never participated in any open discussions.) These are people who have tested or used a specific product for a while, but not necessary currently an active user.

Figure 5 shows the growth of the accumulated community populations of these 4 projects. Currently OpenStack has the larges accumulated community population, followed by Eucalyptus, CloudStack, and OpenNebule.

The problem is, after years of changes, a long-term (such as 4 to 5 years) accumulated community population might not be a good reference for community activeness. Some of the early members of one community might have switched to other communities (and probably more than once), some of the early community medium (such as mailing lists and forums) might have become EOL’ed. From a community analysis point of view, it might be better to count the accumulated community population of the past 6 to 12 months, while extending the range to the dinosaurs age will make this parameter meaningless.

Figure 6 shows the monthly population growth of the four projects being discussed. During the past 6 months, the populations of OpenStack is growing much faster than the other three projects. CloudStack is also exhibiting significant growth, but not as fast as OpenStack.

The populations of Eucalyptus and OpenNebula are growing at relatively slow paces, as compared to CloudStack and OpenStack.

Figure 7 is a combination of Figure 4 and Figure 6. The solid lines represent the monthly participants, while the dash lines represent the monthly new members.

During the past 12 months, for OpenStack and CloudStack, around 30% of their monthly participants are new members.  For OpenNebula and Eucalyptus, around 50% of their monthly participants are new members. This indicates OpenStack and CloudStack communities are becoming more “sticky” than OpenNebula and Eucalyptus communities.

Figure 8 shows the total community population, active participants of the past quarter, and active participants of the past month, of the four projects being discussed. It can be seen that

(1) OpenStack has the largest total population, followed by Eucalyptus, CloudStack, and OpenNebula;

(2) OpenStack has the largest active population during the past quarter, followed by CloudStack, Eucalyptus, and OpenNebula;

(3) OpenStack has the largest active population during the past month, followed by CloudStack, Eucalyptus, and OpenNebula.

We also calculated the ratio of  active population during the past quarter over total population. The result is 36.3% for OpenStack, 24.2% for CloudStack, 11.8% for OpenNebula, and 4.3% for Eucalyptus. Obviously a significant portion of OpenStack and CloudStack users choose to stay, while the majority of Eucalyptus users decide to leave. Such observation is in accordance with what we saw in Figure 7 - OpenStack and CloudStack communities are more “sticky” than OpenNebula and Eucalyptus communities.

In our CY12-Q3 report, we invented the concept of “Community Activeness Index”. Starting from CY13-Q3, we make some minor revision to this parameter, and it is now the combination of the following parameters:

(1) quarterly messages, which represents the volume of the discussions;

(2) quarterly participation ratio, which represents the average number of answers to a question; and

(3) active population of the past quarter, which represents the possibility to get help from community in the long term.

In this analysis, we choose the average values of these parameters as the reference data set, and compare the corresponding parameters of each community with the reference data set. Then we call the sum of the relative values of a community the “community activeness index” of the community. Now we can say the project with the highest “community activeness index” is THE most active project in this area.

As can be seen from Figure 9, OpenStack is currently THE most active project (with obvious advantage), followed by CloudStack, Eucalyptus, and OpenNebula.

We are seeing increasing number of suggestions to analyze the git activities of these open source IaaS projects. We also noticed that all of these four projects use git as the SVM for their source code. Starting from our CY13-Q1 report, we tried to do some basic analysis base on the git log data. It should be noted that for the OpenStack project, the data source includes all the sub-projects under openstack (57 sub-projects) and openstack-infra (33 sub-projects) on github.com.

In our CY13-Q1 report, we used “git log” to obtain log information. Starting from CY13-Q2, we will use “git log –no-merges” to obtain log information.

Figure 10 shows the monthly number of commit operations for these four projects. Generally speaking, the commit frequency of OpenStack is much higher than the commit frequencies of the other three projects. This is because the data source for OpenStack includes a total number of 90 sub-projects, which is far greater than the other three projects. The commit frequency of CloudStack is also significantly higher than Eucalyptus and OpenNebula. As compared to OpenNebula, Eucalyptus was also committing more frequently, but with significant fluctuations from month to month, which seems to be a typical batch-commit behavior. The commit frequency of the OpenNebula project is relatively small, with an average of 200 commits per month.

Figure 11 shows the monthly number of commit operations for the sub-projects of OpenStack. Generally speaking, the commit frequency of the Nova sub-project is about 3 times as high as the other sub-projects. It should be noted that although the commit frequency of these sub-projects are different, but they exhibit similar time-series curves, and their highs and lows occur at the same period of time. This indicates that although these sub-projects are relatively independent, but they work around the same development plan and the same release schedule. This is an indicator that the OpenStack project is well organized in terms of sub-project management.

Figure 12 shows the monthly number of contributors (identified by unique github.com accounts or email addresses) for these projects. Generally speaking, the number of OpenStack contributors is much higher than the other three projects, and is growing rapidly. The number of CloudStack contributors also exhibits some growth, but the growth is relatively slow. The number of Eucalyptus and OpenNebula contributors is relatively small, and does not exhibit growth during the past 12 months.

Figure 13 shows the monthly number of contributors (identified by unique github.com accounts) for the sub-projects of OpenStack. It can be seen that the number of Nova contributors is about 3 times as big as the other sub-projects.

People usually try to identify the institute to which a contributor belongs to by his/her email address. It is true that such method is defect in nature (different institutes have different policies regarding contributing to open source projects, some institutes even encourage their employees to contribute to open source projects with their personal account), but still this parameter can be used to show the contributions of certain institutes to certain open source projects. Figure 14 shows the monthly number of unique institutes (identified by the domain name of the contributor’s email address) contributing to these projects. We can see that the number of contributing institutes for OpenStack is much larger than the other three projects, and is growing rapidly. The number of contributing institutes for CloudStack is also growing, but at a relatively slow pace. The number of contributing institutes to Eucalyptus and OpenStack is relatively small, and does not exhibit any growth during the past 12 months.

Figure 15 shows the monthly number of contributing institutes to the sub-projects of OpenStack. It can be seen that the number of contributing institutes for Nova is about 3 times as big as the other sub-projects.

The following table lists those institutes that make the most contributions to these projects during CY13-Q3, according to the number of commit operations, along with the percentage of their commit operations. It can be seen that both Eucalyptus and OpenNebula are open source projects dominated by single institutes, while CloudStack and OpenStack are open source projects contributed by multiple institutes. For the CloudStack projects, influence from Citrix is still quite obvious, over 48% of the commits come from accounts belonging to citrix.com and cloud.com (3% decrease as compared to CY13-Q2). For the OpenStack project, redhat.com contributed to 15% of the commits, while ibm.com contributed 11% of the commits, hp.com contributed 5% of the commits, rackspace.com contributed 4% of the commits, and mirantis.com contributed 4% of the commits.

The following table lists those institutes that make the most contributions to the sub-projects of OpenStack during CY13-Q3, along with the percentage of their commit operations. We notice that UnitedStack – a nascent cloud computing startup – is making significant contributions to almost all aspects of OpenStack. We also notice that Intel is beginning to contribute code to OpenStack. We all know that Intel is a firm supporter of OpenStack since the formation of the OpenStack project. In the early days Intel used to maintain a fork of an earlier version of OpenStack, which prevented Intel from contributing to the mainstream. Obviously the Intel folks now realize that it is better to join the mainstream than working on an in-house version of OpenStack.

For your convenience, a PDF version of this presentation can be downloaded from here. Please kindly keep the author information if you want to redistribute the content.

A SIDE NOTE

Because of the increasing level of social instability in China, I am seriously looking for the opportunity to continue my career in cloud computing outside of China. If your company is looking for an experienced person to work on technology evangelism, community management, marketing and communication, or business development, please kindly let me know and let’s see whether there is any possibility to cooperate. Yes I do need your company to provide assistance to apply for a work permit (such as H1B in the US, or sub-class 457 in Australia, or whatever applicable) in your country. Should your company provide the option to work from remote, I can get started in China before moving to your country. Furthermore, I do not request your company to cover the relocation expense for me and my family.

You are welcome to take a look at my professional profile on LinkedIn, with recommendations from my previous employers. An updated version of my resume (PDF version) is also available for your reference.

I can be reached via email (qjiang@ieee.org), or video interview via Skype.

Comments (1)

By qyjohn, July 31, 2013 8:17 am

众神与战士 －－ 爱尔兰神话与传说

马楠楠的恶作剧

马楠楠时常在爱尔兰各地游荡，以恶作剧著名。人们又称他为奥东尼的克恩。

故事的经过是这样的。奥东尼在贝拉哈举行盛宴，客人们对他的房子和乐师赞不绝口。就在他们自吹自擂的时候，外面来了一位丑陋的陌生人。陌生人穿着一身破烂的衣服，鞋上全是污泥，身后拖着一把没有剑鞘的剑。他的头上披着一件破烂不堪的斗篷，耳朵从破洞里露了出来。他的手里拿着三把冬青木制作的长茅，黑如焦炭。

陌生人来到奥东尼的面前，和奥东尼互相问安。奥东尼询问他的来历，陌生人说：“我是一个快乐的流浪汉。我有时候住在伊勒，有时候住在希昂，有时候住在喇克莱，有时候住在芙娲山上。昨天晚上我还在阿尔班王的领地蒙奈德那里，今天我就来到您这儿了。”奥东尼派人把门卫叫来，责备他未经允许就放了个流浪汉进来。门卫分辨说这个人他根本就没有见过，更别说是放进来了。陌生人说：“放过那可怜的门卫吧。我可以悄无声息地进来，也可以悄无声息地出去。”所有人都大为惊奇，因为没有人能够不经过大门进入房间。

乐师们开始演奏音乐。他们都是全国最好的乐师，演奏的也是非常动听的乐曲。但是陌生人大声说道：“奥东尼，你们的乐师是在打铁吗？再也没有比在这里听这些噪音更糟糕的事情了。”陌生人自己拿过竖琴来，开始弹奏。听了那美妙的声音，哪怕是临产的妇女和受伤的士兵都忍不住恬然入睡。奥东尼对陌生人说：“我早就听说过在山里隐居的西荷人和他们的音乐。但是这还是我第一次听到这么美妙的音乐。您真是个招人喜欢的乐师。”陌生人回答说：“我只是有时候招人喜欢，有时候则招人讨厌。”

奥东尼派人搬来椅子，请陌生人坐在他的身旁。陌生人说：“我可不愿意这样。我宁可做我的小丑，为你们这些高贵的人取乐。”奥东尼又派人给陌生人送来衣服、帽子、衬衫和外套，但是他不愿接受，说：“我可不能让你们这些高贵的人夸口说曾经给我施舍过什么东西。”

人们意识到这个陌生人非同寻常。为了不让他离开，他们派了二十位骑兵和二十位步兵守在屋里，又在屋外派了更多的人把守。陌生人说：“你让这么多人围着我是什么意思呢？”奥东尼回答说：“他们是要把你留在这里的。”陌生人说：“相信我，今天我定然不会在这里和您共进晚餐。我要在德斯幕麦的科诺艾讷和伊耳的儿子希格汗共进晚餐。”奥东尼则、回答说：“如果你在明天天亮之前惹出什么乱子的话，我就把你拍成肉饼。”

陌生人又拿起了竖琴，象刚才那样弹奏起甜美的曲子。就在大家专心倾听的时候，他对外面的卫兵们说：“现在我要走了。好好把我看住吧，不然你们就把我弄丢了。”卫兵们听了这话，抓起斧头就往陌生人身上砍去。但是他们都被自己人的斧头看中，接二连三地倒在地上。陌生人对奥东尼说：“如果你还想救活这些人的话，就给我二十头牛和一百亩土地作为赎金吧。现在把这些草药拿去，揉碎了放在每个人的嘴里，他们就会原封不动地复活。”陌生人得到了奥东尼许诺的二十头牛和一百亩土地，又把卫兵们救活了。

伊耳的儿子希格汗正在自己的圆形房屋前面的草地上举办一次集会。同样，他看见来了一位丑陋的陌生人。陌生人穿着一身破烂的衣服，鞋子还滴滴答答地往下滴水。希格汗向陌生人询问他的来历。陌生人自称杜阿丹，那是一位远近闻名的学者的名字。他说：“我从伊丝卢达来，一路上经过塞克兰、科尔山、达哥达的马格罗尔、海科纳尔、马格艾的克鲁禅，最终走到您这里来。”人们把陌生人带进屋里，给他酒喝，又给他水洗脚。陌生人洗完脚后，倒头就睡，一直睡到第二天的早上。伊耳的儿子希格汗又前来拜访陌生人，说：“您昨天的旅程实在是太长了，难怪您睡了这么长时间。您的学问和琴艺闻名遐迩，今天我非常希望能够当面见识一番。”陌生人说：“是的，我的学问很大，并且善于弹琴。”人们给他拿来一本书，但是他一个字也不认得。人们给他拿来一把琴，但是他一首曲子也不会弹。希格汗抱怨说：“你的学问和琴艺都丢光了吗。你的名字叫做杜阿丹，但是既不认识字又不会弹琴。这不是一件很奇怪的事情吗？”陌生人看到希格汗上了当，就把书拿起来，用甜美圆润的声音从头到尾读了一遍。他又拿起竖琴自弹自唱，就像前一天他在奥东尼家所作的那样。希格汗赞叹地说道：“您真是一位招人喜欢的智者。”但是陌生人回答说：“我只是有时候招人喜欢，有时候则招人讨厌。”

希格汗陪着陌生人一起在科诺艾讷散步。他们正走着的时候，陌生人突然间就不见了。不管希格汗怎么找也找不到他的踪影。

马楠楠继续在爱尔兰各地游荡，来到了康纳特的司理伽。康纳特的女巫被穆恩斯特的女巫抢走了一个魔法花篮。康楚巴带着康纳特的人马前往穆恩斯特进行报复。马楠楠乔装成一个名叫基拉的仆人，加入了康纳特人的队伍。他们骑着牛和马还有羊等等一切可以骑的动物，经由塞安楠来到穆恩斯特。他们从穆恩斯特的女巫家里抢走了一头无角的公牛和两头花母牛，作为对康纳特女巫损失的魔法花篮的赔偿。

但是穆恩斯特人在康纳特人回去的路上截击了他们。基拉问康楚巴是想早点把牛赶回家去，还是要给穆恩斯特人一个教训。康楚巴说最好是给穆恩斯特人一个教训。于是基拉独自带着一张弓和二十四支箭留下断后，一直到康楚巴带着人马安全回到康纳特。

有一回，基拉到康楚巴家去作客。康楚巴没有把第一杯酒送给基拉，而是自己把第一杯酒喝了。这可把基拉惹恼了，立即就离开了康纳特。

然后他穿着以前的破衣服烂鞋子到了达达格那里。人们问这个陌生人都会什么本领。他说：“我是个完杂耍的。如果你给我五个马克，我就给你们表演一个杂技。” 达达格说：“我可以给你五个马克。”陌生人收下了五个马克，然后在手上放了三根灯芯草，说：“现在我要把中间那根灯芯草吹走，但是旁边的两根灯芯草完好无损。”陌生人用两个指头夹住旁边两根灯芯草，一口气把中间那根灯芯草吹走。达达格夸奖陌生人说：“这真是个不错的杂技。”但是达达格手下有个人不服，说：“这算什么杂技。你给我一半的钱，我也可以给你表演同样的事情。”陌生人说：“如果你也能够做到的话，我可以把我得到的钱分一半给你。”那个人也在手上放了三根灯芯草，试图把中间那根灯芯草吹走。就在他设法夹住旁边两根灯芯草的时候，他的两根手指头扎穿了他的手掌。陌生人大声说道：“哎唷。我可不是这样表演的。不过你已经输了钱，我可以把你的伤治好。”

陌生人又说：“现在我要给你们表演另一个杂技。我可以让一只耳朵动起来，但是另一只耳朵不动。”达达格说：“好啊。那就让我们见识一下吧。”陌生人抓住自己一只耳朵，上下摇动。达达格说：“嗯。这是个不错的杂技。”陌生人看出了达达格不以为然的表情，又说：“等着。现在我要给你们表演一个真正的杂技。”

陌生人从包里掏出一根丝线往天上扔去，那丝线一下子窜到云上。他从包里掏出一只兔子，那兔子嗖的一声顺着丝线爬了上去。他接着从包里掏出一只小狗，那小狗一边吠叫一边追那兔子。他又从包里掏出一个僮仆，让他顺着丝线去追小狗和兔子。然后他拿出另外一个包来，从里面掏出一个漂亮的姑娘。陌生人让姑娘跟在僮仆和小狗后面，不能让小狗把兔子吃掉。 达达格看到姑娘、僮仆、小狗和兔子在空中追逐嬉戏，不由得开怀大笑。

过了一小会，空中安静了下来。陌生人说：“恐怕是上面发生了点什么事情吧。” 达达格问：“会是什么事情呢？”陌生人说：“我猜小狗正在吃兔子，僮仆正在调戏姑娘。”达达格说：“嗯，很有可能。”陌生人把丝线拉了下来，他们看到僮仆正在跟姑娘做爱，小狗正在啃兔子的骨头。陌生人勃然大怒，拔出剑来砍下了僮仆的头。 达达格不悦地说：“我可不喜欢您在我的面前做这样的事情。”陌生人说：“如果您乐意的话，我还可以把他变回来。”他拿起人头扔向僮仆的尸体，人头自动粘到颈脖上。僮仆站了起来，脸部却是反的。 达达格说：“如果是这样的话，那真是生不如死了。”陌生人抓住僮仆的头把它扭正，就像以前那样完好如初。做了这些事情以后，陌生人突然就消失了，没有人知道他去了哪里。

这就是马楠楠在爱尔兰四处游荡、搞笑逗乐、装神弄鬼的故事。没有人能够把他留在任何地方。即使他将自己陷于危险之中，他总是能够安然无恙地全身而退，并且让那些嘲弄他的人吃尽苦头。但是他的玩笑通常是无害的。那些被他用魔法杀死的人，总会被他包袱中的草药救活。

马楠楠只吃酸奶和海棠果，不吃任何其他食物。世界上没有任何音乐比他所演奏的音乐更加甜美。

Comments (0)

By qyjohn, July 10, 2013 8:01 am

众神与战士 －－ 爱尔兰神话与传说

马楠楠

现在我们来讲一讲可敬的马楠楠的故事。马楠满是李尔的儿子。达楠人被盖尔人打败后，马楠楠让达楠人隐居在山林之间，并在居住点周围筑起隐形的墙。安顿好达楠人之后，马楠楠独自离开了爱尔兰。有些人认为他已经死了，并且确信他是在战斗中被犹兰杀死的。他们绘声绘色地说战斗发生在马格崔兰，而马楠楠是被站着埋葬的。马楠楠被埋下之后，一个大湖从他的脚下冒了出来。这个湖以马楠楠的一个外号起名，叫做欧泊辛湖。直到现在，这个地方还是一片红色的沼泽。芭妲在这场战斗中取得了胜利，很多女人在这场战争中失去了丈夫。

但是后人又多次在爱尔兰见到马楠楠的踪迹。国王康奈尔的母亲伊妲藏匿在牧牛人家里时，马楠楠派出信使为伊妲传递信息。德尔德莉的孩子们很小的时候，马楠楠将他们藏在苹果林里抚养成人，人们称那个地方为“暴风骤雨中的一片净土”。马楠楠教会芬族的迪安努德使用武器，也是马楠楠教会库丘林使用标枪盖堡。甚至有人说马楠楠就是德尔德莉的父亲。当尤斯得尔的王康楚巴寻找德尔德莉的时候，马楠楠变成一只兔子跑在尤斯得尔人的猎犬前面，将康楚巴带到德尔德莉藏身的地方。

传说康楚巴将尤斯那的后代包围在玛姹城堡，遭到了他们的英勇反抗，不能取胜。康楚巴请求马楠楠的帮助，但是马楠楠拒绝了。实际上，马楠楠早就警告康楚巴说德尔德莉会使他的王国土崩瓦解，并不顾康楚巴的反对为德尔德莉提供庇护。康楚巴转而恳求马楠楠暂时蒙住尤斯那家族的眼睛，不然他的军队就会全军覆没。马楠楠考虑再三，答应了康楚巴的请求。尤斯那的后代杀出城门，与尤斯得尔的军队作战。但是他们突然双目失明，在黑暗中自相残杀，一个个死在自己人的手下。但是也有人说马楠楠和这件事没有关系，是巫师卡特巴达用魔法将尤斯那的后代淹死在大海里。

马楠楠有很多个化身。有人说铁匠库莱恩就是马楠楠的化身之一。库丘林后来继承了铁匠库莱恩的名号。

在来到尤斯得尔之前，库莱恩曾经到过法咖岛，那里是马楠楠的居住地之一。康楚巴来到尤斯得尔之前，曾向一位巫师请求忠告。巫师让他到法咖岛去请求名叫库莱恩的铁匠为其打造武器。康楚巴来到法咖岛，遇到了铁匠库莱恩。库莱恩答应为他打造宝剑、长矛和盾牌。

库莱恩忙着为康楚巴打造武器。一天早上，康楚巴到海滩上去散步，看到一位海美人在海滩上睡觉。康楚巴对梦中的海美人施了个咒语，使得她无法逃跑。海美人醒来后，发现自己被康楚巴德的咒语困住，便恳求康楚巴恢复她的自由。她说：“我是蒂亚巴哈，海里的女神。你让库莱恩把我的形象和名字刻在你的盾牌上。只要你带着这盾牌，你的敌人就会闻风丧胆，而你的人马则勇气倍增。”

康楚巴将海美人放回大海，让铁匠按照海美人的吩咐打造盾牌。他回到爱尔兰之后，果然是盾牌在手，所向披靡，战无不胜。后来康楚巴将库赖恩请到爱尔兰来，并在暮易赫姆纳平原上划了一块地盘供他居住。不管他是不是马楠楠，康楚巴显然是从他那里受到了很好的教育。

传说马楠楠有一批优秀的猎犬，但是它们全都死在一次狩猎活动中。那时，有一头野猪在爱尔兰各处游荡，所过之处，一片狼藉。马楠楠派出所有的猎犬紧追不舍。野猪跑到一个大湖边上时，湖水突然奔涌而上。所有的猎犬都被卷入湖中，非死即残，但是野猪安全跑到湖心的一个小岛上。这个小岛就被命名为猪岛，而这个湖就被叫做犬湖。

国王康奈尔有一个养女名叫楚娲，美貌出众。康奈尔让楚娲住在妲珐山上，又安排多位酋长家的公主陪伴着她，打算将来把她许配给某位酋长。马楠楠看到楚娲年轻貌美，便指使自己的学生菲蒂亚去诱骗她。菲蒂亚是达楠人，也是一位巫师。他伪装成成康奈尔王室的仕女混入妲珐山，找到了楚娲的住所。他用一首催眠曲将楚娲迷倒，并将她带到格拉斯港口。他把楚娲放在沙滩上，想要找一艘船将她送到永生的国度。但是一阵巨浪袭来，楚娲不幸溺亡海中。马楠楠大怒不已，立即杀死了菲蒂亚。从那时候起，格拉斯港口的海浪也被叫做楚娲巨浪。

有一回，马楠楠的三头奶牛在贝勒的海边出现。其中一头是红色的，一头是白色的，一头是黑色的。人们看见奶牛们站在海滩上，就像是在思考一样。过了一会，它们并排走上岸来。那时候爱尔兰还没有大路。人们惊奇地发现，它们所到之处，就有一条宽阔的大道在它们的面前出现。大概走了一英里左右，三头奶牛就分开了。白色的奶牛走向西北的路易奈特，红色的奶牛沿着蜿蜒的海滩走向西南，黑色奶牛走向东南的里斯莫尔。同样，在它们的面前各出现一条大道。这些道路一直到现在都还能够看到。

传说马楠楠以笛卡尔的身份来见芬尼亚，并把芬族带到海底世界。他经常和芬族一起打猎，并经常给他们各种帮助。