Add DPG: Social Income

[dpgabot]

Automatic addition of a new digital public good submitted through the online form available at https://digitalpublicgoods.net/submission

[ssandino]

Anything we can do from our side to get Social Income to be added to the list?

[nathanbaleeta]

Checklist for conducting technical review against DPG Standard:

• Clear Ownership
• Platform Independence
• Documentation
• Mechanism For Extracting Data
• Do No Harm By Design
• Data Privacy & Security
• Adherence to Standards & Best Practices
• Adherence to Privacy and Applicable Laws
• Inappropriate & Illegal Content
• Protection From Harassment
• Development & deployment countries

[nathanbaleeta]

Social Income uses Firebase for the development platform and mainly leverages the following proprietary tools:

• Firestore for data management
• Firebase Authentication for user management
• Firebase Hosting to serve static content like the admin app
• Firebase Functions to run backend code in a serverless framework

Social income is dependent on proprietary software (Google's Firebase and other platform-specific APIs) for its core functionality and if removed from the solution, this will impact the overall solution.

@ssandino Could you prove independence from the above proprietary software dependencies or could you verify Social income can perform it's core functionality without relying on Firebase for data management, user management etc?

PS: We do not consider a digital solution to be platform independent if a core service (mandatory) requires a proprietary software dependency unless the latter can easily be switched for an open alternative without overhauling the entire codebase.

Cc: @iperdomo

[ssandino]

@ssandino Could you prove independence from the above proprietary software dependencies or could you verify Social income can perform it's core functionality without relying on Firebase for data management, user management etc?

The firebase setup can be replaced by supabase postgres. The open source database, also offers authentication, storage and edge functions. By using the Firestone data migration tool from supabase a switch is possible. (for security purposes this requires that our existing users with a login set a new password through the "password forgotten" link.)

You mentioned "easily switched" as a requirement. Honestly, I think "easily" doesn't exist as metric in the complex world of digital tools with high security standards. Even if there are migration tools, like in our case, that promise seamless migration there is always testing involved, bugs show up, and developers have to find solutions for some issues.

[ssandino]

are there any other questions?

[nathanbaleeta]

are there any other questions?

@ssandino kindly list the best practices adhered to during the design and development of the digital solution. Thanks.

Hint: https://github.com/DPGAlliance/publicgoods-candidates/blob/main/help-center/best-practices.md

[iperdomo]

4. Platform Independence - When the digital public good has mandatory dependencies that create more restrictions than the original license, proving independence from the closed component(s) and/or indicating the existence of functional, open alternatives that can be used without significant changes to the core product is required.
   Source: https://digitalpublicgoods.net/standard/

Emphasis mine.

The fact the whole platform depends on Google Firebase offerings make it not platform independent.

It's true that Supabase could be a migration path from a proprietary platform to an open source one, but as it was pointed out, the code will need to be adapted to different dependencies (modules) and API calls. That means requiring significant changes to the core product.

[ssandino]

Thanks for your thoughts. Supabase meanwhile offers a great OSS migration tool which migrates the Auth, Firestore, Storage and Functions to the Supabase. This would actually make things quite easy and therefore, I would argue that there wouldn't be much code changes and especially not "requiring significant changes to the core product." This interoperability solves to great parts the dependency, which comes with using proprietary platforms.

[iperdomo]

Thanks for the reply.

This would actually make things quite easy and therefore, I would argue that there wouldn't be much code changes and especially not "requiring significant changes to the core product."

Similar to the previous comment on "easily" doesn't exist as metric, you're suggesting that there will little core product changes. Would you mind creating a branch following with the code changes required?

Just for the record, this is not the first time Firebase users are requested to provide and open alternative. When Supabase was suggested, the project made the actual changes to prove the little/no-changes to the core product. e.g. #928

[ssandino]

Thanks for the quick feedback. We have – as probably most OSS projects – too much development work ahead of us (aligned with the mission to support people in need). It would seem a stretch and hard to understand, why we make a hypothetical change to a new platform. Something which seems to be already proven by the other applicants you mentioned or by the open source community. Thanks for your understanding, working with the open source developer community is always challenging, as tasks have to always come with a clear objective, and there are just too many other issues which seem more purposeful than a "proof of argument branch" (which can easily take a few hours).

Cc: @iperdomo

[ricardomiron]

Digital solutions that previously applied through the legacy process and didn't conclude their application are requested to re-submit their application via the new DPGA nominations portal. I'm closing this PR as per the archiving policy.