Future plans for this package

[Josh-Dovey]

Now that this package has been moved over to the maplibre organisation will it be updated/improved as often as the maplibre-gl-js package?

I understand both packages use completely different technologies, but will the maplibre organisation focus more of their resources into this package to keep it as feature rich and stable as possible?

For example, as flutter continues to update and eventually progresses to version 4, will this package be maintained to keep up to date?

[josxha]

@m0nac0, @wipfli, @nyurik, @birkskyum I think, it would be good to get some more attention to this issue. Reading #221 the package was transfered to maplibre to encorage more users to contribute.

After the migration to the maplibre organization, the maintainence of this package still relies on @m0nac0 as a single maintainer. I explicitly don't want to step on his toes as I am glad for every bit people are willing to put into open source. Sadly though he became inactive in the last 2 months and left his project in an unclear state.

As the flutter/dart ecosystem has countless smaller packages I'd say forking is quite common. However, as this package is part of maplibre I'd prefer to keep it active and prevent a split of the community.

As far as I am aware, the current state of this package is like this:

• The maplibre dependencies are out of date on all platforms.
• The releases to pub.dev are out of date (0.16 vs 0.18 on GitHub releases)
• The package isn't compatible with gradle 8.
• There are open pull requests that haven't been reviewed or have open questions since some weeks.

It would be awesome to see this package become more active again. Therefore I'd like to encourage this discussion about future plans of this package that has been started by @Josh-Dovey. Maybe spreading the workload on more hands could help?
If I can help with anything, just let me know.

@m0nac0, if you want to keep maintaining this package yourself, that's of course completely fine too. Some insight would be really helpful. 👍

[wipfli]

Thanks for the ping @josxha.

The MapLibre Organization has two project tiers, see https://github.com/maplibre/maplibre/blob/main/PROJECT_TIERS.md#tiers.

Core Project

A project that the MapLibre Organization is committed to long-term. A substantial amount of resources is allocated to the project in the form of paid Maintainer time and paid Bounties to ensure its long-term success.

Hosted Project

A project that the MapLibre Organization does not allocate any resources to. The project is hosted in the MapLibre GitHub organization to facilitate collaboration between the people who are interested in the project.

So far only the core rendering libraries MapLibre GL JS and MapLibre Native are in the core tier and receive as such resource from the MapLibre budget.

Flutter MapLibre GL is in the hosted tier and with this we aim to facilitate the collaboration of interested parties. @m0nac0 has been an amazing maintainer and contributor in the past, thanks for all you have done!

If a new person would like to help maintain this repo, they can contact me and we can set up the access rights. Usually we would like to see 2 or 3 good pull requests before granting write access. However, if there is a special situation without reviewers we can also change that requirement.

[matthiscock]

@m0nac0 Also thanks for your time and efforts, and also any time and effort you have moving forwards. We - as part of the community are incredbly greatful.

@josxha - Hello! And thank you for offering to help, and yes I agree with you post - the more who can contribute the better it will be for everything.

We (Senses), which includes @Josh-Dovey would like to extend our support and help with anything we can. While the technology of the package is probably a little out of our reach, we are still happy to contribute on active packages, whether it be in help, testings or documentation - and of course code where we can.

Secondly, we are happy to offer bountys to areas where we want to see improvements. Im happy to offer one to get everything up to date as a starter. Is this something @josxha you would be interested in?

Performance wise, this is the best mapping solution on Flutter, so I would hate this become adbandoned.

[josxha]

If a new person would like to help maintain this repo, they can contact me and we can set up the access rights. Usually we would like to see 2 or 3 good pull requests before granting write access. However, if there is a special situation without reviewers we can also change that requirement.

Sounds good. I'll contact you after the project stayed inactive for some more time. Though, I haven't contributed to this package yet. So if there is any common contributor interessted, that's probably a better solution.

We [...] would like to extend our support and help with anything we can. [...] we are still happy to contribute on active packages, whether it be in help, testings or documentation - and of course code where we can.

That's great news!

Secondly, we are happy to offer bountys to areas where we want to see improvements. Im happy to offer one to get everything up to date as a starter. Is this something @josxha you would be interested in?

I like the concept of bounties and I'm interessted in general. However, I need to give it at this point a pass. Don't get me wrong, it's great that you want to enhance your support to this flutter package but requiring a bounty each time to have a dependency updated, makes it easier to life from a forked version.
Bounties are great for new features, performance improvements or even some bugs. But in my opinion, there should be some solution that doesn't relies on bounties to have this project up-to-date or to get pull requests reviewed. E.g. there are some open pull requests that want to update some parts of this package:
- gradle 8: #382 and #390
- maplibre-native 11 for android: #396 (comment) (although there is much more going on in this pr)

As this project is a hosted project, an (or multiple) active voluntarily maintainer(s) would fit best, like it has been in the past.

[matthiscock]

@josxha it was more to help you onboard if you wanted to be that person to take on that initial challenge you identified.

The main goal is to keep this alive, and fighting fit.......

[josxha]

@matthiscock sorry, I misunderstood your first message. Yes, can do. 👍

[kuhnroyal]

I have done some work on the cocoapods and general release stuff in the past. Starting June I would be willing to put some time into this.

IMO, the main goal should be to get this package actually publishable in a reproducible manner.
Afterwards we can start iterating on actual fixes and features.

[josxha]

@matthiscock I red through the different slack discussions about this project and have now much more context and a better understanding for this project. Additionally I got familar with the MapLibre bounty program after reading through the related articles and applied for the developer pool.

I still think that it's great news that this project should get a bigger role as a package in the flutter world as it's potential and wants to put a bounty on it. Thanks a lot for the commitment! Could you give some details on the scope? If you are a bit out of touch with the flutter ecosystem, I can write you a list that I consider should be included to get the list of requirements started.
IMO improving release cycle to pub.dev is only one of the things that need to be done.
If needed, I'am available on the osm slack (username @josxha).

[wipfli]

I granted maintainer access to Peter Leibinger (@kuhnroyal) to Flutter MapLibre GL since he asked if he can help maintain the project. Peter has already a bunch of merged pull requests and I am very thankful that he helps maintaining this project. So, welcome to the group
@Peter Leibiger
!

[kuhnroyal]

Thank you!

[josxha]

As the dart/flutter team pushes towards WebAssembly, the Dart JS interop has changed by quite a bit. Dependencies have changed and the JS object wrappers need to be redone.

There are two quite different possible paths:

• Migrating the current maplibre-gl-js wrapper to be compatible with Flutter on WebAssembly.
• Or focussing on an ffi solution that has been already requested here:
  • Flutter bindings maplibre-native#41 (comment)
  • FFI Design Proposal maplibre-native#1254

[Etheonor]

I'm not the best person to help you keep this project going, but I am a user of the library and I thank you from the bottom of my heart for keeping this repo alive!

[kuhnroyal]

Thanks! @josxha and myself will try to get a mostly non-breaking release out asap. Afterwards there will be breaking changes in small increments that hopefully allow for a somewhat step by step migration path.

[kuhnroyal]

We now have a 0.19.0+2 or ^0.19.0 release up on pub.dev - all packages are now published and no git references should be needed anymore.
Please let us know of any problems via comment or issue.

[Josh-Dovey]

Thanks for all your work @kuhnroyal @wipfli @josxha and all others who have been involved in the latest release! I hope this repo continues to be maintained. I would love to be able to assist directly but I understand that I would be completely out of my depth. I'll continue to use it in my flutter apps and will provide feedback.

Once again, I appreciate all your work!