sounds good. Important work that keeps the app running should be paid with our open collective money.

@Laurent Savaete and I talked about this on the MapSwipe call today.
@Laurent Savaete says he will add his main pieces of work for the React Native upgrade, as well as listing out some things he did and does not plan to bill for. Acknowledging all the effort even if not actually billed we both thought was important.

This whole process started with Travis shutting down their free access for open source projects back in December 2020. While they claim that they still support open-source projects for free, we now have to request credits in maximum instalments of 25,000. We did this to test out their process and got credits about 2 months after our request. The 25k were used up in less than a week when Benni did some development work. There was nothing unusual in how he did his work, and this showed that using travis was simply not a viable option for the project. To keep using the platform, we would have to request credits every time they ran out, and wait for Travis to provide them to us at their whim. As the entire app release process is done through our CI (Continuous Integration, the process we run on travis), waiting for 2 months is just not an option.

From there, we took the decision to move our process to GitHub actions, which seems most likely to remain free for us for the foreseeable future. As this was a blocker for us (mainly for @Benni who was trying to implement new features in the app), I started doing the work with the overall agreement that we would figure out how to pay for it after its completion. This job was almost done after about 2 days of work (see detailed breakdown of hours below) but...

As we had not released any update to the app in close to 6 months, Apple had in the meantime updated some policies around minimum software versions required, which meant that we were not able to publish any new version of the app. To get around that issue, upgrading React-Native seemed to be the most reasonable course of action. The reasoning was that Apple required the use of minimum versions of various libraries (for the app to work well on the latest version of iOS), which meant compiling the app with XCode 12.x (we were using 11.x at the time). In turn, compiling the app with XCode 12 brought up a bunch of issues, which seemed most easily solved by upgrading React-Native. This in itself took around 2 days of work.

But this upgrade in turn required that we upgrade other libraries that were having issues with the newer versions of XCode or React-Native. Most notably react-native-firebase ("RNFb"). We use this for all our database access, for authentication (logging in to the app) as well as remote notifications (which we had to disable temporarily as the feature was removed from the latest version of RNFb). This same logic cascaded into a bunch of other dependencies that became incompatible with the newer libraries we had already upgraded.

As a side note, it's important to understand that this process of upgrading libraries is a normal part of maintaining the app. We have been doing this since I started working on it in 2018, and the first big upgrade to MapSwipe 2.0 was exactly that: upgrades of dependencies one after the other, without any new functions.

We hit a few bugs with the appstore release process, one of them due to my lack of attention to details where I forgot to set an environment variable, which sadly the code did not complain about. Finding this issue took almost a day of work (which I won't bill). We also had to spend some time updating privacy related declarations with Apple following their changes in policies. And finally we hit a bug in the upgraded version of RNFb after the release of version 2.1.4. which I eventually fixed in the library we use.

I mention all these details to give a sense of the cascade of events that led to extending the workload from an initial estimate of 2 days to about 11. All of these upgrade were jobs we had listed in github to do sooner or later (except the bugs that popped up during the process), but the successive blocking points (our inability to release new versions of the app) forced us to do them all at the same time.

Breakdown of work hours:

- Convert CI from Travis to GitHub Actions: 22.4 hours

- Upgrade React-Native and related dependencies: 25.7 hours

- Prepare the app release and fix various bugs: 26.3 hours

- Debug RNFb issue: 18.0 hours

- Total: 92.3 hours (11.5 days)

Out of these, I would want to bill the first 2 items in full, this was planned work (github tickets #445 and #405). For the other 2 items, I'm happy to wave the RNFb issue, and 1 day (8 hrs) off the app release process as mentioned above.

This would add up to 22.4 + 25.7 + 18.3 hrs = 66.4 hrs. I've usually billed my time for MapSwipe and non-profit projects at 400€/day (50/hr), which brings us to 3320€ total.

Takeaways for future similar projects:

- This was the first occurrence of work to be paid through OpenCollective, we had glitches in the process, but we should aim to keep the good parts and avoid the bad ones. Hopefully this can serve as a precedent for future jobs.

- Doing the work before having agreed on payment is probably not something we should reproduce. We did this here because we were blocked from doing any other work, and we have worked as a team long enough to trust that things will work out positively.

- The cascade of problems we faced here comes in big part from having done nothing on the app maintenance for several months (the previous release was in January 2021). The mobile app ecosystem is constantly moving, with both Apple and Google changing what is and isn't allowed on their app stores. As a reminder of this, as we finally released the latest app version (2.1.5) on the playstore, google notified us that we would soon need to upgrade the "target API" that we compile the app for on Android before November this year. Done in time and separately from other issues, this is not a major problem, as it's not blocking and can most likely be done in 1-2 hours. But leaving it unattended until past the deadline means that we are barred from doing anything until the problem is solved, and most likely the issue will cascade again in a variety of problems as we just experienced.

- I think from this point on, we should commit (to the extent that we have the resources for it) to releasing a new version of the app every month or two. Each of these should include minor upgrades to the various libraries we rely on, as well as following the recommendations that Apple and Google provide regularly, before they become blockers. We have opened ticket #546 to collect such items into a checklist which we would run through every month.

- The "bus factor" that I have mentioned before is still an issue. This work could ideally be shared among several volunteers so as to avoid monopolising one person's time for over 2 weeks of work. As @Andrew suggested, we could explore the use of bounties to attract external help.

Hey @Laurent Savaete ,
thanks for providing that detailed break down. Sounds all good to me.

I think especially the takeaways section will be important for us in the future I guess.

Just a minor thing. you initally say "Debug RNFb issue: 18.0 hours" and then "22.4 + 25.7 + 18.3 hrs = 66.4 hrs". So you could adjust the initial number to 18.3.

I'm not 100% sure how to best decide which things you do for free and which things you would get paid for. For me personally it's okay, if you decide this on your own, but could you provide some rationale why you wouldn't bill for "Prepare the app release and fix various bugs: 26.3 hours"? Maybe just as a future guide also for others?

@Benni to answer your questions:
- 18.3 comes from 26.2 - 8, not from 18. This is the app release part of the work, with a day discounted from the total, that I'll consider volunteered work
- I'm not 100% sure how I decide where the boundary between paid and volunteered work is. I think my rationale for the above was that the 8hrs excluded from the release job are excluded because I should really have found the solution in much less time than that. The other part, the RNFb issue, I'm willing to exclude from billing as well because I'll see it as "not directly core MapSwipe work". To be clear, in a normal work context, I would bill for those hours, since they were needed to complete the project, and chasing bugs for hours is very much part of normal software development work.

But in the context of MapSwipe being a volunteer project, I think it's also important that we have some funds left for further work, at least until we know that there will be more financial support coming.
For extra clarity, the total bill for the work above should have been 4615€ (92.3hrs @ 50€), and should we budget for future maintenance, this is closer to what we should consider.

I think it's also worth mentioning that this was a (hopefully) harder than usual update process, and our next releases should be smoother, in particular if we follow the rule of smaller, more frequent upgrades. Sadly, a mobile app is at the whim of 2 giants (Apple and Google) dictating sudden changes in their expectations, and this comes at a cost. It would be interesting to discuss alternative solutions to reduce this cost, having in mind that there would be different hidden costs, for instance if MapSwipe was a webapp instead of a mobile one.

Thanks @Laurent Savaete! Amazing work and thanks so much for documenting everything. Great to have this to learn from and for future reference.

Thanks for addressing the boundary between paid and volunteer work. This is something we need to better define and capture in the governance document. Appreciate your flexibility this time round but we need to make sure it's sustainable and fair - especially for the essential (but often more boring) work to ensure that the app continues to run.

🙌