Add DPG: OTTAA Project

[dpgabot]

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

[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

[jwflory]

I am deeply familiar with OTTAA Project's work and personally worked with @hectoritr the team to help them achieve DPG certification. Based on the submission received and my knowledge of OTTAA Project, it gets a ✅ from me.

However, I do know @iperdomo mentioned Google Firebase was used somewhere in the product. I did not do a deep dive on this part, and it might warrant a deeper investigation on the platform independence indicator. However, if we choose to object to the use of Google Firebase as a dependency, we may need to audit other DPGs and verify whether they have this requirement too, because it may not have been caught in previous reviews.

I turn this one back to @nathanbaleeta and @iperdomo for the next steps.

[nathanbaleeta]

I am deeply familiar with OTTAA Project's work and personally worked with @hectoritr the team to help them achieve DPG certification. Based on the submission received and my knowledge of OTTAA Project, it gets a white_check_mark from me.

However, I do know @iperdomo mentioned Google Firebase was used somewhere in the product. I did not do a deep dive on this part, and it might warrant a deeper investigation on the platform independence indicator. However, if we choose to object to the use of Google Firebase as a dependency, we may need to audit other DPGs and verify whether they have this requirement too, because it may not have been caught in previous reviews.

I turn this one back to @nathanbaleeta and @iperdomo for the next steps.

@jwflory @iperdomo Use of closed licenses/ libraries such Google's Firebase undermines the openness of the project, however if the project owner can provide open alternatives, then we can consider the project to pass the indicator on platform independence. I have contacted Hector on this and will update this submission once we hear from him.

[iperdomo]

Just to clarify the Firebase usage:
https://github.com/OTTAA-Project/OTTAAProject/search?q=firebase&type=code

As of today, 80 code related references.

[hectoritr]

Just to clarify the Firebase usage: https://github.com/OTTAA-Project/OTTAAProject/search?q=firebase&type=code

As of today, 80 code related references.

Hi @iperdomo, thanks for providing the search, of those most of them are imports (I'll check how many of them are really in use) and many others are custom methods and not actual calls to Firebase outside the classes I've already mentioned in our previous emails.

For example
game.subirDatosJuegosFirebase();

Still, I'll clean up the code and get back to you, also we are starting to work on a solution with your proposed method using Interfaces and dependency injection.

Thanks! :)

[jwflory]

Hey all, I got off a quick chat with @hectoritr and wanted to map what the next steps could look like here.

For context, the OTTAA Project team is migrating their existing Java-based version to a Flutter-based version. This work is ongoing and the team is building their capacity with Flutter as they gradually achieve feature parity with the Java version, especially around offline functionality. Given the ongoing work to migrate to a new version and that the Java-based version is on a feature freeze (i.e. only critical bug fixes and maintenance), I propose we swap out the review for this DPG submission from the Java-based version to the Flutter-based version instead.

Firebase is still being used in the new version too, but I think it makes the most sense for the OTTAA Project team to create abstractions for the cloud computing logic in Flutter instead of back-pedaling on the Java-based version, which is likely to be retired or deprecated in the future. I think this puts the OTTAA Project team on track to achieve DPG certification, and also aligns the remaining platform independence piece with their current development focus.

I suggested we keep this review open as the Flutter development continues, and we revisit as needed once the OTTAA Project team is ready for a re-review on platform independence. I thought it was easier just to swap the two repositories here instead of suggesting @hectoritr and the team fill out a new submission. The two repositories are the same app in purpose and functionality, but different code.

Thoughts? Does this make sense?

N.B. @nathanbaleeta: This means we swap the repo in this PR from https://github.com/OTTAA-Project/OTTAAProject to https://github.com/OTTAA-Project/ottaa_project_flutter

[nathanbaleeta]

Hey all, I got off a quick chat with @hectoritr and wanted to map what the next steps could look like here.

For context, the OTTAA Project team is migrating their existing Java-based version to a Flutter-based version. This work is ongoing and the team is building their capacity with Flutter as they gradually achieve feature parity with the Java version, especially around offline functionality. Given the ongoing work to migrate to a new version and that the Java-based version is on a feature freeze (i.e. only critical bug fixes and maintenance), I propose we swap out the review for this DPG submission from the Java-based version to the Flutter-based version instead.

Firebase is still being used in the new version too, but I think it makes the most sense for the OTTAA Project team to create abstractions for the cloud computing logic in Flutter instead of back-pedaling on the Java-based version, which is likely to be retired or deprecated in the future. I think this puts the OTTAA Project team on track to achieve DPG certification, and also aligns the remaining platform independence piece with their current development focus.

I suggested we keep this review open as the Flutter development continues, and we revisit as needed once the OTTAA Project team is ready for a re-review on platform independence. I thought it was easier just to swap the two repositories here instead of suggesting @hectoritr and the team fill out a new submission. The two repositories are the same app in purpose and functionality, but different code.

Thoughts? Does this make sense?

N.B. @nathanbaleeta: This means we swap the repo in this PR from https://github.com/OTTAA-Project/OTTAAProject to https://github.com/OTTAA-Project/ottaa_project_flutter

@jwflory the new Flutter repo is missing licensing information, will update once this is included. Thanks.

[hectoritr]

Hello @nathanbaleeta & DPG Team, we are back. After a lot of work and some frustrations. We have finally developed a really nice architecture, removed GetX as state management, and many more, like our new documentation! :)

We are stoked about your review and looking forward to answering any questions or suggestions you might have.

Master branch can be found here: https://github.com/OTTAA-Project/ottaa_project_flutter

And a branch with Supabase and Dio examples here: https://github.com/OTTAA-Project/ottaa_project_flutter/tree/feat/supabase-dio-impl

We would like your suggestions on how to handle this example branch keeping it separate from main to not increase the file size of the published app.

Best, The OTTAA Team.

Cc: @iperdomo

[iperdomo]

Hi @hectoritr, amazing news on the platform independence piece. Can you confirm us that you also have an abstraction layer for the maps part?

We would like your suggestions on how to handle this example branch keeping it separate from main to not increase the file size of the published app.

This is what companies supporting multiple versions of their system struggle with. Long-lived branches are not easy to maintain, you need to keep backporting the changes happening in the main development branch.

One thing that may be interesting is to have different flavor of the app, See:

• https://docs.flutter.dev/deployment/flavors
• https://developer.android.com/studio/build/build-variants
• https://medium.com/simform-engineering/basic-use-of-android-product-flavors-build-variants-315a4e11e435

[hectoritr]

Hi @hectoritr, amazing news on the platform independence piece. Can you confirm us that you also have an abstraction layer for the maps part?

We would like your suggestions on how to handle this example branch keeping it separate from main to not increase the file size of the published app.

This is what companies supporting multiple versions of their system struggle with. Long-lived branches are not easy to maintain, you need to keep backporting the changes happening in the main development branch.

One thing that may be interesting is to have different flavor of the app, See:

• https://docs.flutter.dev/deployment/flavors
• https://developer.android.com/studio/build/build-variants
• https://medium.com/simform-engineering/basic-use-of-android-product-flavors-build-variants-315a4e11e435

Hi @iperdomo and team!

That's I think a good use case for flavors, we will definitely implement it.

Regarding maps, we are refactoring the algorithm and the Geolocation feature has its own issues OTTAA-Project/Product-Roadmap#11 & OTTAA-Project/Product-Roadmap#16, it is not implemented in the Flutter version yet, but we will definitely follow the same architecture for any new thing we add.

[nathanbaleeta]

Hi @hectoritr, amazing news on the platform independence piece. Can you confirm us that you also have an abstraction layer for the maps part?

We would like your suggestions on how to handle this example branch keeping it separate from main to not increase the file size of the published app.

This is what companies supporting multiple versions of their system struggle with. Long-lived branches are not easy to maintain, you need to keep backporting the changes happening in the main development branch.
One thing that may be interesting is to have different flavor of the app, See:

• https://docs.flutter.dev/deployment/flavors
• https://developer.android.com/studio/build/build-variants
• https://medium.com/simform-engineering/basic-use-of-android-product-flavors-build-variants-315a4e11e435

Hi @iperdomo and team!

That's I think a good use case for flavors, we will definitely implement it.

Regarding maps, we are refactoring the algorithm and the Geolocation feature has its own issues OTTAA-Project/Product-Roadmap#11 & OTTAA-Project/Product-Roadmap#16, it is not implemented in the Flutter version yet, but we will definitely follow the same architecture for any new thing we add.

@hectoritr The link below suggests to us that there is still a direct dependency on Google's geolocation (point of interest) data:

#928 (comment)

Therefore, if we take the new Flutter based application as the source of the submission, then OTTAA Project is not yet platform independent.

Cc: @iperdomo

[hectoritr]

Hi @hectoritr, amazing news on the platform independence piece. Can you confirm us that you also have an abstraction layer for the maps part?

We would like your suggestions on how to handle this example branch keeping it separate from main to not increase the file size of the published app.

This is what companies supporting multiple versions of their system struggle with. Long-lived branches are not easy to maintain, you need to keep backporting the changes happening in the main development branch.
One thing that may be interesting is to have different flavor of the app, See:

• https://docs.flutter.dev/deployment/flavors
• https://developer.android.com/studio/build/build-variants
• https://medium.com/simform-engineering/basic-use-of-android-product-flavors-build-variants-315a4e11e435

Hi @iperdomo and team!
That's I think a good use case for flavors, we will definitely implement it.
Regarding maps, we are refactoring the algorithm and the Geolocation feature has its own issues OTTAA-Project/Product-Roadmap#11 & OTTAA-Project/Product-Roadmap#16, it is not implemented in the Flutter version yet, but we will definitely follow the same architecture for any new thing we add.

@hectoritr The link below suggests to us that there is still a direct dependency on Google's geolocation (point of interest) data:

#928 (comment)

Therefore, if we take the new Flutter based application as the source of the submission, then OTTAA Project is not yet platform independent.

Cc: @iperdomo

Hi Nathan, thanks for the reply.

There is no current implementation of the Geolocation feature in the Flutter code, which is planned to be done in the next quarter. It's my understanding that as is, the code is platform-independent. Or should we add the abstraction for geolocation now? we have not defined yet how it's going to be implemented.

But, we are committed to maintaining platform independence for any new feature that is added to the flutter code, most probably using App Flavors, as suggested by Ivan, to offer an Open Source alternative to the community.

Looking forward to hearing your thoughts on this.

[iperdomo]

Indicator 4 - Platform Independence 👍🏾

[ricardomiron]

It looks good to me, some of the links are broken but I have put the replacements of working ones in the line comments.

Also as a side note, I'm not that familiar with Android Apps but just want to make sure current documentation is sufficient for anyone to be able to use the codebase and run the app.

[nathanbaleeta]

It looks good to me, some of the links are broken but I have put the replacements of working ones in the line comments.

Also as a side note, I'm not that familiar with Android Apps but just want to make sure current documentation is sufficient for anyone to be able to use the codebase and run the app.

@ricardomiron the app is built using Flutter and the documentation is straightforward for launching and run the software. Thank for the pointers to the broken links.