How to keep GGIR alive?

If we want Open-Source research software to remain functional and relevant then an ongoing maintenance effort is needed. At a basic level, the maintenance effort would include the preservation of functionality. For example, fixing major bugs and keeping the software up to date with changes in dependencies. At a more advanced level, the maintenance effort would also cover the improvement of existing functionality, adding new features, and providing support to users.

Software sustainability is a term closely related to software maintenance and refers to two aspects:

• Designing software in a way that eases maintenance.
• The strategy to enable software maintenance over time.

In this blog post I will focus on the second aspect in relation to Open-Source R package GGIR.

Sustainability models

As Open-Source software is free, we cannot use software sales to fund the maintenance effort. Therefore, I had to choose a different model. The model I chose is to maintain GGIR based on paid consultancies. It works as follows: GGIR users contract me to make specific enhancements to GGIR or to provide training on the use of GGIR. The experience and income I generate from doing these consultancies allow me to remain committed to the maintenance of GGIR. Although this has been and still is an effective model, it may be good to reflect on what other models I could use in addition to the consultancy service.

1. Individual sponsorship?

In an individual sponsorship the developer of the software would ask benefactors of the software to sponsor them. An example of this is the GitHub sponsorship model. This model offers two versions:

1a. Sponsorship as form of appreciation:

This sponsorship comes without any commitment from the developer. It is just a way for sponsors to demonstrate their appreciation for the developers’ ongoing efforts to maintain the Open-Source software.

At first, this approach feels tempting to adopt: It is easy to set-up and it reinforces the open science idea that the community sustains the software. However, I also see some problems with the individual sponsorship model:

• Conflict with commercial activities: It could create the confusing impression that I am a charity. I am not sure how I would be able to keep a clear distinction between what I do as a paid consultant and what activities could reflect the sponsorship donations.
• Income insufficient: It is hard to imagine that this form of sponsorship can generate sufficient income to live from.
• Unfair in relation to co-contributors: Sponsorships typically go to well-known developers and less prolific or more junior contributors may then miss out.

1b. Sponsorship as a service:

In this sponsorship type the sponsor expects a specific commitment from the developer. For example, to be available for a call once per month or to give higher priority to the needs of a sponsor. Sometimes this is done in the form a retainer agreement. The challenges I foresee here are:

• Users may not need long term support: Once the client knows their way around GGIR the need for support will reduce, while the need for maintenance efforts continues. As a result, the service will effectively turn into the before mentioned ‘sponsorship as a form of appreciation’.
• Hard to define a standard service description: Some GGIR users may only need minor support, while others GGIR user require substantial time investments. This makes it difficult to come up with a standard service model. Asking for €1000 per year would seem expensive for the first group but cheap for the second group.

2. Project-based sponsorship?

Examples of sponsorship at project level are the sponsorships provided by NumFocus and CZI. Project-based sponsorship makes it easier to share sponsorship income across developers compared with the individual sponsorship as discussed above. Further, if I would register as a foundation, which some of these sponsors require, it would become easier to separate project-based sponsorship from commercial activities. Nonetheless, for GGIR a project-based sponsorship may not be the most intuitive approach:

• Sponsorships typically designed for teams: It appears that most sponsorships are designed to help teams-based organisations, while in the case of GGIR maintenance is primarily done by me alone. Of course, I could start assembling a team, but in the initial phase all the administrative and coordination burden will be on me.
• Limited amount of funding opportunities: Both NumFocus and CZI are based in the United States. I am not aware of any European sponsorships for Open Source software that I am eligible for. Most opportunities seem to be restricted to academic researchers only.

Project-based sponsorships are potentially valuable but are best led by an academic researcher familiar with grant applications.

3. Linking Open-Source software to commercial products and services?

At the moment I have no plans in this direction, but in theory I could offer the following services:

• Cloud service to provide data analysis.
• Exclusive faster second version of GGIR that can only be used with a specific accelerometer brand.

A part of the revenue generated from these services could then be used for maintenance of the software. My feeling for now is that both ideas require a level of expertise that I do not have.

4. Advertisements?

Incorporating advertisements in software is common with mobile phone apps. In the case of GGIR, I already make subtle advertisement for my consultancy services as Accelting. If I wanted to get external advertisers, then I am not sure who would be a good candidate advertiser. The strength of GGIR is that it works across accelerometer brands, so allowing accelerometer manufacturers to advertise their product inside GGIR does not seem fitting. However, other forms of advertising may work fine. Interested? I am happy to have a chat.

Conclusion

The best route forward seems keeping the focus on my paid consultancy for the following reasons:

• A clear commitment between me, doing the work, and the client paying me.
• Paying clients ensure that all maintenance efforts are tailored to the most urgent needs of the user community.
• It counters the idea that Open-Source software is inherently unsustainable and should be supported like we support charities. By doing business based on Open-Source software I demonstrate the value and sustainability of GGIR as Open-Source software.

That said, this shouldn’t stop anyone else from contributing to GGIR in complementary ways.

How you can contribute?

• Are you in a position to apply for funding to help improve GGIR? If yes, please do so, and I’d be more than happy to collaborate and support you where needed.
• Do you have software development skills and are you in a position to help contribute to GGIR then, again, please do so. Being part of the open source software community is rewarding in itself!
• If you know of any other sustainability model not listed here then let me know.