Acknowledge valid reasons for HFOSS be apparently less friendly and seek constructive solutions

[fititnt]

There are valid reasons for FOSS to generally have difficulty answering a contribution, and it is expected that Humanitarian FOSS may have additional seasonal difficulties.

A traditional FOSS could have a larger community who is able to contribute with code, or be partially backed by one or more companies who use their employees as developers. In other hand, the humanitarian version could be maintained by some seasonal funding or with volunteers who could be not able to be available in a timely manner.

As this repository listing HFOSS is trying to focus on to be very welcome to external developers contributions we could find inspirations on FOSS in general about how to welcome external help, and consider the context of humanitarian applications.

[fititnt]

Here my opinion at this moment.

Let's assume as example one example of worst case scenario: where a HFOSS do not have any core developer able to maintain the software, and a person who answers one developer who contributed with code does not know if its should or not be accepted.

This is a very valid reason and very common on my experience. As could be more common some HFOSS be initially created founding or by bigger seasonal donations, the organization who initially create it or the organizations who are actively using could be locked in and have people without development skills to decide what to do with a contribution.

The typical consequence

The default result here would be HFOSS, in special the more older ones, stop to have any improvement even if have people willing to offer small improvements.

As is common to any FOSS, the delay in accepting code suggestions or give feedback stops contributions.

One possible win-win alternative

Since HFOSS software are more unique (after all, they have an humanitarian intent) would be possible to when a maintainer answer that is not able to understand if the suggestion should or not be accepted, the person find someone specialized on the same software stack used by the HFOSS and both should agree about what to do; maybe asking for one additional external specialized developer on the same stack if the two developers do not agree with the technical improvement or technical fix. Then, since the maintainer of HFOSS do not have any internal developer to check or not the final result, it will accept any final agreement of the external contributors.

Considerations:

1. This alternative does not require wait for have the bureaucratic work to have internal developers again to the maintainers.
2. The maintainer can disagree with the new feature or fix because are considering the end user side or require some way to be able to test the implementation before it was merged to the main code repository

Final thoughts

Since these software are for humanitarian usage, and that the pool of humanitarian software is much smaller than open software in general, with some work on the developers community, is possibly to find some experts on some software stacks who would serve just as this type of moderator.

Senior developers know the importance of these contributions, as they normally have experience that some of these contributions could at some point become permanent maintainers for HFOSS who lack of volunteers.