{"id":3256,"date":"2012-10-06T22:11:54","date_gmt":"2012-10-07T03:11:54","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=3256"},"modified":"2013-02-20T20:05:41","modified_gmt":"2013-02-21T02:05:41","slug":"how-sina-contributes-to-openstack","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/how-sina-contributes-to-openstack\/","title":{"rendered":"How Sina Contributes to OpenStack"},"content":{"rendered":"

OpenStack launches a new release every 6\u00a0months. Essex was released 6 months ago, and Folsom came out on September 27. Every release \u00a0is followed by a third-party report on the individual and corporate contributions. In this article, \u00a0I’d like to talk about how we Sina OpenStack dev team, as an important corporate contributor in OpenStack projects, involves in the OpenStack\u00a0community and how we contribute to OpenStack Folsom ?<\/p>\n

6 months ago, in a report of\u00a0Who Wrote OpenStack Essex?<\/a>\u00a0by\u00a0ReadWriteWeb, we were surprised to see that Sina was for the first \u00a0time listed\u00a0among\u00a0Top 10 bugfix companies, ranking #9. My team was highly inspired, and we never thought that our little work in OpenStack could be able to be listed along with the International IT giants, like Rackspace, RedHat, IBM and HP. \u00a0Since then, we have devoted much more weight on the community development of OpenStack official projects, and\u00a0 invested more resources and encouraged all team\u00a0members \u00a0to engage in OpenStack community development\u00a0as well.<\/p>\n

As a result, we have\u00a0achieved much progress during Folsom release\u00a0according to the statistics from\u00a0openstack-gitdm<\/a>, which is maintained by\u00a0Mark McLoughlin, an OpenStack contributor from Red Hat, \u00a0and provides the\u00a0contribution data<\/a>\u00a0extracted from git commits, Gerrit and launchpad\u00a0for 7 core projects of OpenStack during the whole Folsom release.<\/p>\n\"\"<\/a>\n

In general, we have contributed 147 patches to the 7 core projects of OpenStack, ranking #4; having 74 bugfix been approved, also ranking #4; \u00a011,787 lines of code been merged, ranking #8, and we have 18 stackers who have code contributions in Folsom release, ranking #2 after Rackspace. \u00a0Bitergia\u2019s report on Folsom<\/a>\u00a0using different toolset and methodology also concludes the\u00a0similar result.\u00a0\u00a0(More\u00a0statistical graphs\u00a0are shown in the photo gallery bellow)<\/p>\n

Moreover, we have been involved in the\u00a0collaborative developments of all the\u00a07 core projects, which means we have balanced investment in these projects, and we believe this strategy \u00a0will benefit us in better understanding the whole OpenStack frameworks and different\u00a0components. If only counted by the number of patch, we ranked #6 in Nova, #3 in Quantum, #3 in Cinder, #6 in Glance, #3 in Keystone and #11 in Horizon.<\/p>\n

But why, how and what\u00a0did we Sina OpenStack team contribute to OpenStack community and OpenStack projects?<\/p>\n

Why and How?<\/h1>\n

In the mid of 2011, when the Diablo release was under heavy development, we decided to use OpenStack as our underlying system of Sina IaaS public Cloud, Sina Web Services(SWS), and another strategic product besides Sina App Engine(SAE), which is developed by my former team members and already the most popular public PaaS cloud in China. \u00a0But then OpenStack was full of bugs, not very stable and not ready for production deployment, and also lacked \u00a0some essential components, such as billing, monitoring and load balancer etc. So we invested several engineers to do bugfix, to implement new features and to design\u00a0necessary\u00a0services. In the\u00a0beginning, we forked an internal branch from a particular commit of OpenStack, and had much development on the internal branch. Later we found that it is a little difficult to merge upstream updates to our own branch, if this condition did continue, our project would be\u00a0dangerous\u00a0since it would go more and more far way from the official projects, and we would finally lose the community and the ecosystem. So we stopped the trend immediately and cut down our own fork. Instead, we joined the community,\u00a0collaborated with gurus around the world, and combined the requirement of our own public cloud projects and need of OpenStack community, so that we could be able to avoid duplicated development, and it has become a win-win game for the community and my employer. In fact, we have contributed all our bugfixes and feature improvements to upstream. We also opened sourced our own implementation of \u00a0biling(Dough<\/a>) and monitoring(Kanyun<\/a>). We benefited a great deal from \u00a0this change.<\/p>\n

First, most importantly, many of my team members have \u00a0grown up from a newbie to an\u00a0experienced and\u00a0qualified OpenStack contributor\u00a0through the collaborative community development in a short time, thus in turn the progress of our own projects were\u00a0speeded up\u00a0\u00a0with such quick learners.<\/p>\n

Second, by means of contributing our own feature implementations and open-sourcing additional projects, we got lots of valuable\u00a0feedback\u00a0from PTLs, core developers and the community, guiding us to better software design and \u00a0implementation.<\/p>\n

That’s why and how we are \u00a0involved in the community\u00a0development\u00a0and contributing to OpenStack.<\/p>\n

What?<\/h1>\n

Besides code contribution\u00a0mentioned\u00a0above, what else have we done for OpenStack in the last 6 months?<\/p>\n

As the early OpenStack dev team who operates the first production OpenStack cloud in China, we have done lots of work to promote OpenStack in China, as well as building COSUG to be the most active and influential open source user group in China. To be specific:<\/p>\n