One Year in the openATTIC Team: A Summary

Removing Barriers and Refining Processes

One big step was that we removed the "Enterprise/Community Edition" split and published the entire openATTIC code base under the GPLv2 license exclusively. There is no more dual licensing funkyness.

We also dropped the requirement for submitting a contributor license agreement (CLA), in order to lower the barrier for new developers to submit patches to us. Today, all that is needed is to sign off your submitted patches, similar to how the Linux kernel and many other project do it.

This has also changed our business model: instead of "selling software", we'll now focus on delivering services and support around it. This part is still under development, but the plan is to provide the usual offerings in the form of support and software subscription plans. We'll share more details about this when we've finalized our planning here, but if you have some ideas and expectations around this, we'd like to hear from you!

We also changed many processes and ways in which we worked on the code base, to accelerate and improve the development.

For example, we consolidated code of various components like documentation, test suites and the former "Enterprise" features into a single Mercurial repository, to simplify the development and release process. This makes it easier to submit changes that affect all these components in an "atomic" fashion (e.g. when committing a new feature implementation including the related tests and documentation).

Furthermore, we started making more effective use of Mercurial branches. We switched to using a stable/development branch model and having a Jenkins instance as the "gatekeeper": only if all tests have passed on the development branch, a merge into the default branch is performed automatically.

This ensures that we can theoretically cut a new release from the default branch at any time, with high confidence. The stable branch is also used for building our nightly snapshot builds and is the code base used on our live demo, which gives us additional test coverage.

To reduce the turnaround time for bug fixes and for new features to be available shortly after they have been committed, we also switched to a monthly release schedule. This means that if some feature did not make it in time for a release, another one is always around the corner, and a developer does not have to wait for months to get his work incorporated.

We also opened our development processes: all of our work (bugs, new features, enhancements) is now tracked in a public Jira instance. Changes to the code base are proposed in the form of public pull requests and code reviews.

Infrastructure Improvements

In addition to moving the formerly internal Jira instance to the public, we further extended our project infrastructure by also adding a public Mumble server as well as an Etherpad for collaboration purposes. We also established a Google Group so our users can get in touch with us, to discuss existing features as well as new functionality.

The openATTIC blog was moved from a shared WordPress blog to a dedicated instance based on the Nikola static site generator. The motivation was to lower the bar for our developers to generate content without having to leave their usual work environment. Posting a new blog post now only requires creating a text file in reStructuredText markup (the same we use for the openATTIC documentation), commit and push the change and trigger a Jenkins job to rebuild the site.

We attended and participated in numerous events and conferences, to spread the word about openATTIC.

Community Reception

These activities in opening up and to foster a community around openATTIC have already resulted in some notable activities.

For example, we established a development cooperation with SUSE, to help accelerating the Ceph management and monitoring capabilities within openATTIC and to port openATTIC to the SUSE Linux platform. We also had joint presentations at conferences and webinars with them and visited the SUSE Hackweek.

We have started initial discussions with some hardware vendors, to discuss the bundling of their systems with openATTIC in the form of pre-installed appliances. We're in the early stages here, but it's exciting to have these conversations and to learn more about the requirements and issues raised by these partners.

A group of four students from Pune (India) will perform development work on openATTIC as part of a research project for their final year of college. They are currently working on setting up their development environments and getting familiar with the code base, and we look forward to their first contributions.

A group of developers in Malaysia has expressed interest in the Ceph management part of openATTIC and is currently testing it on their production site. Moreover, they are looking into developing an alternative UI prototype for the Ceph management, it will be interesting to see what they come up with.

In general, traffic on the #openattic IRC channel and our Google Group has picked up noticeably and we're also receiving first code contributions from external developers.

We've actually created a dedicated page that lists low hanging fruit tasks that should be suitable for new developers to get started.

I think we're heading in the right direction with the changes and improvements that we've implemented. We're still in the early stages, but the trend indicators look promising. We look forward to working with a growing community of users and developers!