One of the things you’d expect from an active open source project is that the code base is likely to grow as more and more features are added.
In An exploration of open core licensing in network management I mentioned that one possible side effect of open core software is the creation of a functionality ceiling.
A functionality ceiling is a level of functionality beyond which the community edition product manager is unwilling to implement because of the fear that the enterprise product will be less attractive to potential customers.
That got me thinking, if a functionality ceiling does exist, how can I demonstrate it?
The graphs below are taken from the Ohloh open source project directory. The rather useful thing about Ohloh is, in addition to cataloguing open source projects, it also performs extensive code analysis.
The two graphs below are taken from the Hyperic code analysis and the Zenoss code analysis pages on Ohloh.
Hyperic Code Analysis Graph
Zenoss Code Analysis Graph
Both of the graphs clearly show a plateau in the quantity of code committed to the respective community edition code repositories. There may be a number of explanations for the plateau, perhaps heavy re-factoring work clears the space required by new features. Though, realistically I doubt that re-factoring would be capable of continually reducing the size of the code base in order to make way for new code.
The plateau look suspiciously like evidence that open core software, at least in the network management world, tends towards a functional ceiling.
Great post. Check out this project:
http://www.ohloh.net/p/OpenNMS/analyses/latest
It’s a slightly different graph.
Of course I’m going to be biased, I’m the Community Manager for Zenoss, and you know what they say about statistics. ;p
Ohloh’s numbers are a bit skewed because of the way the way it counts contributions and because we re-organized our repositories and build system last year. Developers started working exclusively in sandboxes and the documentation output (HTML and PDFs) is no longer checked into the source tree; so the number of commits and volume has decreased considerably. If you look at the statistics, you see that it considers Zenoss 72% HTML, which is documentation that is no longer checked into Subversion (and Python isn’t even listed in our top 4 languages, despite being a Python application). There is a major-rearchitecting going on right (converting to Python 2.6 and Zope 2.12) now that is about to move into Subversion trunk and a large spike will be coming in the next few days. The next major release of Zenoss Core has a tremendous amount of new functionality. I’m quite certain the statistics for our ZenPack repository are being left out, since they’re in another repository and came online last January (http://zenpacks.zenoss.org 2600 files). I expect that if you were to account for the over-counting of faulty data, include all of our repositories and move the window to the end of March you would get a very different graph.
I got the ZenPacks repository integrated now, the statistics and the graphs are already looking a little more balanced. Like I mentioned in the previous comment, there are several very large spikes about to occur, so feel free to revisit this in a month and the thesis of this post will be completely negated (at least with respect to Zenoss).
[...] Musings upon the open core functionality ceiling – does a functionality ceiling exist in open core [one of mine again] [...]
[...] Musings upon the open core functionality ceiling [...]