Turnover of Companies in OpenStack: Prevalence and Rationale

This paper examines the withdrawal behaviour of corporate contributors to OpenStack, which seems particularly relevant given most contributions in OpenStack are corporately supported, and corporate engagement is declining over time. Its also directly relevant to my own experiences contributing to the project, so seemed like a thing I should read.

One interesting aspect of the study is how they define withdrawal from contributions. For each company, they calculate an individual frequency of contribution, and then use that to determine if the company is still making contributions. That is, of a company only ever contributed once a year, we must wait at least a year to know that they have indeed stopped contributing.

The paper finds that in more recent OpenStack releases, more companies are leaving contributions than joining. The authors assert that in general engaged developers are now less experienced than previously, which presents risks in terms of developer effectiveness as well as code quality. However, the paper does note that companies with smaller contributions are more likely to disengage than “sustaining companies”, however that’s largely because there are a huge number of companies contributing only one developer who makes a small number of commits.

Unsurprisingly, the paper notes that companies which contribute more are more likely remain as contributors — both because of momentum, but also because they’re more likely to have a say in the roadmap direction of the project and therefore whether it fits their needs or priorities. They use some loaded words like “dominated by a small number of contributors”, but I don’t think that’s really helpful given that other companies could choose to contribute if they wanted to. I think some of this behaviour is what I would call “rent seeking” — players who contribute little but think that the project somehow owes them changes to make their commercialisation successful. The researchers also note an additional factor here — OpenStack isn’t well suited to small environments, so larger organizations are more likely to have a successful deployment and therefore stay as contributors.

Overall I’d describe this paper as not particularly groundbreaking, but perhaps useful when trying to decide what behaviour to encourage in an Open Source community in order to make a project sustainable.

pngtools, code that can nearly drink in the US

I was recently contacted about availability problems with the code for pngtools. Frankly, I’m mildly surprised anyone still uses this code, but I am happy for them to do so. I have resurrected the code, placed it on github, and included the note below on all relevant posts:

A historical note from November 2020: this code is quite old, but still actively used. I have therefore converted the old subversion repository to git and it is hosted at https://github.com/mikalstill/pngtools. I will monitor there for issues and patches and try my best to remember what I was thinking 20 years ago…

On Selecting a Well Engaged Open Source Vendor

Aptira is in an interesting position in the Open Source market, because we don’t usually sell software. Instead, our customers come to us seeking assistance with deciding which OpenStack to use, or how to embed ONAP into their nationwide networks, or how to move their legacy networks to the software defined future. Therefore, our most common role is as a trusted advisor to help our customers decide which Open Source products to buy.

(My boss would insist that I point out here that we do customisation of Open Source for our customers, and have assisted many in the past with deploying pure upstream solutions. Basically, we do what is the right fit for the customer, and aren’t obsessed with fitting customers into pre-defined moulds that suit our partners.)

That makes it important that we recommend products from companies that are well engaged with their upstream Open Source communities. That might be OpenStack, or ONAP, or even something like Open Daylight. This raises the obvious question – what makes a company well engaged with an upstream project?

Read more over at my employer’s blog

PNGtools 0.4

Wow, this is a blast from the past. When I wrote the pngchunks command in 2003, I had never seen a 64 bit machine, and knew enough to check that an int was the right size, but not enough to just use the guaranteed-to-be-32-bit version from day 1. I’d pretty much forgotten about this code until I got pinged about this Debian bug. The bug reporter is entirely right, this was lame.

PNGtools 0.4 should be 64 bit safe. The pngchunks command works on my 64 bit machines at least.

A historical note from November 2020: this code is quite old, but still actively used. I have therefore converted the old subversion repository to git and it is hosted at https://github.com/mikalstill/pngtools. I will monitor there for issues and patches and try my best to remember what I was thinking 20 years ago…

Mirror traffic during the last day of LCA 2007

It seems obvious to me that videos of LCA 2007 are good. Specifically:

 IPTraf
 # Statistics for eth0 ##########################################################
 #                                                                              #
 #               Total      Total    Incoming   Incoming    Outgoing   Outgoing #
 #             Packets      Bytes     Packets      Bytes     Packets      Bytes #
 # Total:       241091    228940K       96646   18025370      144445    210915K #
 # IP:          241091    225548K       96646   16655328      144445    208892K #
 # TCP:         241086    225547K       96643   16655034      144443    208892K #
 # UDP:              4        412           2        266           2        146 #
 # ICMP:             0          0           0          0           0          0 #
 # Other IP:         1         28           1         28           0          0 #
 # Non-IP:           0          0           0          0           0          0 #
 #                                                                              #
 #                                                                              #
 # Total rates:      49188.4 kbits/sec        Broadcast packets:            0   #
 #                    6592.2 packets/sec      Broadcast bytes:              0   #
 #                                                                              #
 # Incoming rates:    3814.2 kbits/sec                                          #
 #                    2714.4 packets/sec                                        #
 #                                            IP checksum errors:           0   #
 # Outgoing rates:   45374.2 kbits/sec                                          #
 #                    3877.8 packets/sec                                        #
 # Elapsed time:   0:00 #########################################################
  X-exit

Yay for LCA 2007 videos.

The Linux Australia mirroring project

Some of you might be aware that Linux Australia recently agreed to support a trial open source mirror project for Australia. This mirror is being run by a sub-committee of Linux Australia, on hardware owned by Linux Australia. The purpose of this post is to remind people of the project, and give a quick status update. It has to be quick, as I’m really busy this week.

Our hardware arrived several weeks ago, and having been kindly configured by Andrew Pollock was ready for deployment about a week ago. This deployment was held up with some illness amongst various players, but the hardware was deployed to the data center last week by Steven Hanley and myself. We’re currently finalising network ACLs for the machine before we can work on finishing off the software configuration.

At this time I would like to ask for suggestions of projects which would benefit from mirroring. Preferably there would be a clear benefit to the community in Australia from such a mirror, and support from the people being mirrored for the concept. Bandwidth isn’t a problem, and disk isn’t a big deal as long as the suggestion doesn’t need hundreds of gigabytes.

I’ll keep you posted as things progress.

[btags:]
[icbm: work]