Asterisk and the way the project is organised in numbers for presentation

General
3

Prologue

As a caveat to this response, I’m going to note that as the CTO of Digium, I’m going to be giving you a biased answer. Wherever possible, I’m going to try to separate the “just the facts” answers from what is opinion.

Organizational Structure

Asterisk is an open source project that is owned and supported by Digium. Contributors to the project agree to license their work to Digium under Digium’s CLA. Asterisk itself is licensed under the GNU General Public License version 2, and is available under alternative commercial licenses through Digium.

The Asterisk project is organized using the “benevolent dictator” model (although not for life), with the dictator historically always coming from/being appointed by Digium. The “dictators” (hereafter called “leads”) throughout the project have been, in order:

  1. Mark Spencer, the founder and creator of both Asterisk and Digium
  2. Kevin Fleming
  3. Russell Bryant
  4. Matt Jordan (hi!)
  5. Matt Fredrickson

In addition to providing the lead for the project, Digium maintains a team of software engineers and community managers to assist with the project. The team - known internally as swdev (which is an increasingly inaccurate name, as there are arguably four or five software development teams at Digium) - currently consists of the following members:

  1. Matt Fredrickson - Project Lead
  2. David Duffett - Community Director
  3. Rusty Newton - Community Manager
  4. Mark Michelson - Asterisk Developer
  5. Joshua Colp - Asterisk Developer
  6. Richard Mudgett - Asterisk Developer
  7. Scott Griepentrog - Asterisk Developer
  8. George Joseph - Asterisk Developer
  9. Kevin Harwell - Asterisk Developer

In addition to working on Asterisk - which includes everything from fixing bugs, writing new features, improvements, tests, and documentation - the members of the swdev team maintain Digium’s Asterisk commercial modules (codecs, DPMA, etc.) and the project community sites (JIRA, Gerrit, Confluence, FishEye, Git Mirrors, Jenkins, etc.). They also write entries for the Asterisk blog.

Outside of the Digium team, there are many, many developers within the community. It’s difficult to categorize community developers, as by definition, Digium has no control over what anyone else works on, how often others contribute, or whether anyone contributes at all. In the past, when Asterisk was on Subversion, there was some delineation between those community developers with commit access and those who merely provided patches from time to time. However, since the project has moved to Git, everyone has equal access to the project and to provide patches to the project. As such, anyone who submits a patch to Gerrit is technically a community developer.

And as an aside, Digium is part of the community. In my opinion, drawing a distinction between a developer employed by Digium and one employed by another company shouldn’t have a bearing on normal day to day development.

Asterisk Development

Patches to the project are submitted for inclusion via Gerrit, which acts as both a Git repository as well as a code review system. All patches are reviewed openly. Anyone who has signed a CLA may contribute a patch and participate in the review. Anyone can approve a patch (give it a +1), just as anyone can ask for it to be improved (give it a -1). Anyone can also reject a patch (give it a -2); doing so, however, should be done extremely rarely and only with a strong technical rationale, as it implies that the patch, no matter the improvements, shouldn’t be merged. Typically when this is done, it is done because a different patch has been proposed that solves an issue/provides a feature using a different approach.

Anytime a change is proposed to the project, a series of continuous integration checks are run against the patch. Any failure in the automated tests will automatically cause the patch to receive a negative verification score. The author is responsible for fixing issues found by the automated tests.

On the team, the project lead and a few other people have “blessing authority” (give it a +2) on Gerrit to cause an approved patch to be moved into the merge pipeline. In general, this is just an administrative task, and isn’t used to approve or reject patches. Once in the merge pipeline, Jenkins runs selected tests in the Asterisk Testsuite to verify the patch and, if the tests pass, the patch is automatically merged.

Core Developers

The Asterisk project doesn’t really have a formal definition of ‘core developers’ versus ‘other contributors’. The only real difference is between those who work at Digium and those who don’t. In the domain of patch contribution, that’s primarily just an employment distinction. Anyone in the project can +1/-1/-2 a review.

In reality, of course, things are a bit more complex than that. There are members of the community who, by virtue of being:

  • Around and active in the project for a long time
  • Active on the issue tracker, documentation efforts, and/or code reviews
  • An extended (community supported) module maintainer
  • Simply extremely prolific developers

Are known by other developers and have trusted opinions.

So, if you view ‘core developers’ as those who contribute a lot, then the Digium swdev team certainly counts as that, by virtue of being employed to work on Asterisk. Outside of the swdev team, who constitutes as part of the ‘core developers’ has changed over the years. Looking at the past year of commits to the ‘master’ branch, the non-Digium developers with more than 10 commits are:

  • Corey Farrell
  • Alexander Traud
  • Alexei Gradinari
  • Rodrigo Ramirez Norambuena
  • Tzafrir Cohen
  • Walter Doekes

Community Leaders

It’s important to note that these are just those who contribute code; it is by no means the only people that contribute their time to the project. Other folks contribute in substantial ways to the project by answering questions in IRC, on the mailing lists, or in this forum. It can be difficult to measure this attribute of contribution, since there isn’t a handy Git repo to scrape. Luckily, Discourse provides us mechanisms to measure participation on this forum. By looking at who posts most frequently, along with a bit of qualitative analysis to see if they’re answering questions versus ‘being chatty’, we have:

Asterisk Contributors

The total number of contributors over the entire lifetime of the Asterisk project is difficult to measure. As noted, back in the Subversion days, only certain people had commit access; as such, their commit count will be inflated while the true author of the patch will only be noted in the commit message. Sometimes as well an author will go by multiple names or handles; for example, you’ll find commits from me under “Matt Jordan”, “Matthew Jordan”, and “mjordan”. We’ve written some scripts to determine this by scraping the commit messages and ‘massaging’ the results to map author’s names and handles together. Over the past year, the following people have contributed to the project:

  • Richard Mudgett Richard Mudgett: 179
  • George Joseph George Joseph: 134
  • Joshua Colp Joshua Colp: 75
  • Corey Farrell Corey Farrell: 60
  • Matt Jordan Matt Jordan: 60
  • Mark Michelson Mark Michelson: 56
  • Alexander Traud Alexander Traud: 54
  • Alexei Gradinari Alexei Gradinari: 38
  • Kevin Harwell Kevin Harwell: 28
  • Rodrigo Ramirez Norambuena Rodrigo Ramirez Norambuena: 16
  • Tzafrir Cohen Tzafrir Cohen: 14
  • Walter Doekes Walter Doekes: 11
  • Timo Teräs Timo Teräs: 8
  • Badalyan Vyacheslav: 5
  • Diederik de Groot Diederik de Groot: 5
  • David M. Lee David M. Lee: 5
  • Rusty Newton Rusty Newton: 4
  • Scott Griepentrog Scott Griepentrog: 4
  • Jaco Kroon Jaco Kroon: 4
  • Etienne Lessard Etienne Lessard: 4
  • Dade Brandon Dade Brandon: 4
  • Torrey Searle Torrey Searle: 4
  • Jacek Konieczny Jacek Konieczny: 3
  • Jean Aunis - Prescom Jean Aunis - Prescom: 3
  • Frank Haase Frank Haase: 3
  • Aaron An Aaron An: 3
  • Daniel Journo Daniel Journo: 3
  • Sean Bright Sean Bright: 3
  • Michael Kuron Michael Kuron: 3
  • Jonathan Rose Jonathan Rose: 3
  • Alexander Anikin Alexander Anikin: 3
  • Sebastian Gutierrez: 2
  • Leif Madsen Leif Madsen: 2
  • Christof Lauber Christof Lauber: 2
  • snuffy snuffy: 2
  • Philip Correia Philip Correia: 2
  • Badalian Vyacheslav Badalian Vyacheslav: 2
  • Gianluca Merlo Gianluca Merlo: 2
  • Eugene Voityuk Eugene Voityuk: 2
  • Michael Walton Michael Walton: 2
  • Andrew Nagy Andrew Nagy: 2
  • Alec Davis Alec Davis: 2
  • Niklas Larsson Niklas Larsson: 2
  • Tyler Cambron Tyler Cambron: 2
  • ibercom ibercom: 1
  • Eugene Eugene: 1
  • Richard Miller Richard Miller: 1
  • Pascal Cadotte Michaud Pascal Cadotte Michaud: 1
  • Steve Davies Steve Davies: 1
  • Grachev Sergey Grachev Sergey: 1
  • Sergio Medina Toledo Sergio Medina Toledo: 1
  • Matt Krokosz Matt Krokosz: 1
  • C.J. Collier C.J. Collier: 1
  • Ward van Wanrooij Ward van Wanrooij: 1
  • Filip Jenicek Filip Jenicek: 1
  • Stefan Engström Stefan Engström: 1
  • Vasil Kolev Vasil Kolev: 1
  • Carlos Oliva Carlos Oliva: 1
  • Francesco Castellano Francesco Castellano: 1
  • Jesper Jesper: 1
  • Leandro Dardini Leandro Dardini: 1
  • Moises Silva Moises Silva: 1
  • Jason Parker Jason Parker: 1
  • Örn Arnarson Örn Arnarson: 1
  • sungtae kim sungtae kim: 1
  • darkskiez darkskiez: 1
  • chris de rock chris de rock: 1
  • Chris Trobridge Chris Trobridge: 1
  • server-pandora: 1
  • Sebastian Damm Sebastian Damm: 1
  • Kirill Katsnelson Kirill Katsnelson: 1
  • Ludovic Gasc (Eyepea) Ludovic Gasc (Eyepea): 1
  • Martin Tomec Martin Tomec: 1
  • Karsten Wemheuer Karsten Wemheuer: 1
  • Evgeniy Tsybra Evgeniy Tsybra: 1

Asterisk Community Scope/Scale

It’s always tough to get a full picture of who all is involved, in some capacity or another, in the Asterisk project. Here though are some statistics:

  • 2589 subscribers to the asterisk-dev list
  • 6301 subscribers to the asterisk-users list
  • 20340 registered users in the Asterisk community sites

Downloads depend on the version/branch, but annually there are typically over 2 million downloads of some Asterisk release each year. Since the Asterisk project does not collect information about its users, much less over some long period of time, there’s no real way to know just where all or how many Asterisk systems there are. We do know from IP hits that nearly every country in the world uses Asterisk.

From discussions with users, the most common deployment use cases of Asterisk are:

  • PBX, either stand-alone or as part of a larger SIP infrastructure
  • Call Center, both inbound and outbound
  • VoiceMail server
  • Generic Media Application Server, generally as part of some larger system

Project Composition

The easiest way to tell what all is in the source code of Asterisk is to just use some tool. Since different tools will count things differently, you will get different answers depending on what you select. I just ran sloccount in both Asterisk as well as the Testsuite (since if you’re developing for Asterisk, you’re going to need both).

Asterisk Statistics

Totals grouped by language (dominant language first):
ansic:       993176 (87.19%)
cpp:          74904 (6.58%)
xml:          30425 (2.67%)
sh:           16571 (1.45%)
python:       14286 (1.25%)
perl:          3076 (0.27%)
objc:          2518 (0.22%)
yacc:          2166 (0.19%)
java:          1672 (0.15%)
tcl:            113 (0.01%)
php:             62 (0.01%)
asm:             46 (0.00%)
awk:             24 (0.00%)

Total Physical Source Lines of Code (SLOC)                = 1,139,039
Development Effort Estimate, Person-Years (Person-Months) = 323.89 (3,886.66)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 4.82 (57.81)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 67.24
Total Estimated Cost to Develop                           = $ 43,752,931
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

Testsuite Statistics

In addition to the generated statistics below, as of today, the Testsuite contains 923 functional tests that run against Asterisk nightly. Subsets of the tests are run on each patch submission.

Totals grouped by language (dominant language first):
xml:          46101 (49.30%)
python:       44295 (47.37%)
ansic:         2139 (2.29%)
sh:             970 (1.04%)

Total Physical Source Lines of Code (SLOC)                = 93,505
Development Effort Estimate, Person-Years (Person-Months) = 23.46 (281.57)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.78 (21.32)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 13.21
Total Estimated Cost to Develop                           = $ 3,169,700
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

How to Contribute a Patch

There is a lot of documentation on the wiki about how to contribute a patch:

  1. An overview: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
  2. How to use the Gerrit code review tool: https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage
  3. Project coding guidelines: https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
  4. Commit message guidelines: https://wiki.asterisk.org/wiki/display/AST/Commit+Messages

That may seem like a lot of guidelines, but consider the following:

  1. Asterisk has been around for a long time - 17 years. In that time, there have been hundreds of contributors. Without a somewhat consistent style enforced on the contributions, the sheer variety of ‘styles’ would be jarring for both regular contributors as well as for new developers.
  2. Asterisk is written in C. As has been noted many times, C is an unforgiving language. It’s challenging enough to get things right - particularly with Asterisk’s heavy use of threads - without having poor programming practices thrown on top of things.
  3. Little things add up: without good syntax styles, some environment may not easily view or edit the source code. Without good organization and design, memory leaks, reference counting leaks, and race conditions will proliferate. Without good commit messages, maintainers won’t be able to understand why a change was made. Without issue references, release notes won’t be generated and users won’t know what was fixed in a version.

As far as veto: the only person who can truly veto a change is the project lead, and that ‘veto vote’ is truly the only thing that separates them from the others in the project. In my time as project lead, I believe I had to use that veto vote one time. My preference - and the preference of I believe all of the project leads (although I am arrogantly speaking for them) - has always been to use a democratic process when making technical decisions. I’m sure we’ve gotten that wrong from time to time, but I do think we try - and that’s the best anyone can do.

Conclusion

While I know this may have been a bit rambling, I hope you found it useful. If there were a few concluding remarks I might say about the Asterisk project, its organization, and how the project manages contributions, it would be the following:

  1. There is no right answer on how to organize an open source project. There are certainly wrong ones, but most approaches consist of picking a solution that balances competing constraints. As an example, the project could have more “relaxed” contribution policies, but would then run a greater risk of introducing regressions into releases, resulting in a loss of users. These things are a balancing act.
  2. The project is a community. Digium is a part of that community, and while we provide a project lead, the project would be nothing without the other developers and users that support the project.
  3. Developers are a small part of a community. Asterisk is lucky to have talented users that assist other users on the forums, mailing lists, IRC, and elsewhere. Those interactions are what make an open source community vibrant.
6 Likes