DDEV 2024 Priorities discussion

[rfay]

Here are some ideas for 2024 priorities, it would be great to hear from the community about these (or other proposals).

Please comment with your opinions about the value of these ideas, their proper prioritization, and other priorities that you might think should be added.

These will be discussed at the March 6, 2024 DDEV Advisory Group meeting, if you're not already on the invite list, please PM me with your email and I'll add you.

1. Continue outstanding user support, even with growth of user base.
2. Improve [Platform.sh](http://Platform.sh) support, including ddev-platformsh and Upsun support
   • This likely requires adding a “build” stage to DDEV, where build-time activities can take place (one-time, on “build” primitive).
   • Upsun support may only extend to Laravel, probably depends on how Platform decides to present it.
3. Continue consistent marketing, including blogs, clear fundraising efforts, newsletter
4. Recruit, train, and add a third paid co-maintainer.
5. Work to make existing maintainers happy with their workload, pay, responsibilities.
6. Consider breaking up ddev-webserver into multiple images/containers:
   • Separate apache and nginx webservers
   • Ability to add other webservers
   • php-fpm (and php) in separate image/container
   • Ability to add other back-ends (like node.js and frankenphp) in addition to current php-fpm and gunicorn.
7. Standardize xhprof usage, move toward xhgui, based on ddev-xhgui
8. Refactor configuration code to promote consistent handling of config (global and project) and generated docs.
9. Improve governance strategy for DDEV Foundation. Discuss governance with community, consider raising the authority level of the advisory group, or create another board. Make sure financial controls are obvious and adequate.
10. Continue and enhance contributor training. Turn training sessions into blogs and docs.
11. Rework and clean up user interface and turn into interactive TUI Rework DDEV UI as a TUI using Bubbletea #5762
12. Rework configuration model using Viper, Rework DDEV configuration model using Viper #5763

[mglaman]

Supporting a Node.js runtime would be great. I want to set aside time to help with that, as it'd be beneficial at work. I'm just not sure how best to. For our use case I am networking a Next.js site with server-side generation to a Drupal site and it's been super easy thanks to both running with DDEV.

[garvinhicking]

Personally I'd rank those:

5
4
1
8
10
9
2
7
3
6

("Just a user", and not easy to rank because all is important. Insert Thanks here.)

I'd personally love have 6 as an option only, I do like the compact webserver single container, I recognize the request though ;)

[ultimike]

I think 3, 4, 5, and 10 are most important for the health of the project.

[claudiu-cristea]

Apart from the points concerning the project ecosystem, for me "6" is the first (see #5497 why)

[JPBarringer]

1. Lay the groundwork for GUIs and other integrations with a standardized and documented API.
   I don't know how much (if any) work would be required for this since I only use DDEV from the command line right now, but this seems like the first step towards enabling a GUI. Maybe OpenAPI-based? (https://www.openapis.org/) or GraphQL?

DDEV Issue: #2110 (Although this is about a full TUI/GUI and the API is a discrete, enabling first step, which may desire its own issue.)

Golang GraphQL libraries: https://graphql.org/code/#go
Golang OpenAPI libraries: https://github.com/go-openapi

2. Keep an eye on WASI and WASM (possibly a beyond-2024 goal).
   This is probably the future, and it's getting close. It could be used for ultra-lightweight DDEV isolates (instead of containers), but could also be used to run DDEV in-browser with a minimal local footprint (in this case you'd be either managing isolates locally or using DDEV over SSH to manage a dev server somewhere else).

This is not limited to Docker but Docker is supporting it. More info: https://www.docker.com/blog/docker-wasm-technical-preview/

(Edited to add the DDEV GUI issue, and OpenAPI/GraphQL Library links)

[JPBarringer]

Absolutely will mull this over and create issues for anything concrete. More generally, the thought process is this:

WASI
WASI is still becoming supported by hosting providers, but I think it's further along than many of us who spend a lot of time with PHP realize, as Javascript/Node hosting providers (running on V8 isolates) have an easier upgrade path. (See: Cloudflare, Vercel, Amazon, Microsoft, etc.

From the "traditional" PHP hosting pov, this is probably still a ways off, as the migration path from VPSes, or cPanel and its ilk is not quite so clear. But Docker and Kubernetes are supporting WASM so the tooling (from a more modern, container-orchestrated PHP dev ops POV) is beginning to become available.

I think the biggest issue is figuring out how the compile step fits into a development workflow. This is, again, often more familiar to JS developers.

Some good early examples of WASM for development would be Wordpress-in-browser or Stackblitz

At the moment, this is mostly just a fun experiment, bordering on over-optimization (improved multi-tenancy is not a huge problem on the average dev machine, and I don't think DDEV is super worried about fully-in-browser development) but as it becomes more common to deploy to WASI cloud providers, this is going to feel more and more important.

API
I would use an API within the context of a GUI. I suggest it because I think it would be cleaner and more maintainable to focus on an API instead of building a TUI/GUI as a first step, without a defined, (versioned, tested,) public API.

An API would enable an internal GUI effort. But it would also allow for external GUI development(s), either platform-specific or simply because a developer wants to organize things differently. I think this could be a huge power-up for the greater DDEV community.

[rfay]

You should know that every ddev command has a -j option to output json. This was implemented years ago for a previous GUI attempt, https://github.com/ddev/ddev-ui

[JPBarringer]

Oh hey that's really cool.

[rfay]

There's an ongoing issue about GUI options, and it would surely expand DDEV's audience. We've never felt we had adequate long term resources to commit to something like that.

[JPBarringer]

An https endpoint that speaks JSON sounds like an API to me. It could live on its own .ddev.site address.

People who want to do something more complex/remote could use a caddy reverse proxy in front of it (for instance).

[kopeboy]

⬆️ 1, 10, 3, 4, 9, 5: to grow the community (you/we deserve it)
❓➡️ 6, 7, 8: I'm not an expert so I don't know
⬇️ 2: platformsh is too expensive, consider supporting other providers as well (and given your open source nature and name which could be read as "Decentralized DEV", I would consider integrating with the leading decentralized cloud: akash.network).

Keep up the good work! 👏🏻 🙌🏻 💪🏻

[rfay]

@kopeboy I'm sure you know that we have explicit support for Acquia, Pantheon, Lagoon, Upsun, and that you can easily configure for any other platform. https://ddev.readthedocs.io/en/latest/users/providers/

[tyler36]

As an end-user, I'm drawn towards item 6, 7, 8 which also align with my abilities and interests .

The list items seem to fall into 3 categories:

• usage/feature (coding)
• community growth and involvment (marketing)
• DDEV Foundation and oversight (managing)

Perhaps prioritising an item in each area is a good approach.

[bmack]

Thanks for the exhaustive list. I think we should consider having a registry for DDEV addons at some point (similar to packagist.org as the registry for composer packages), not as the highest priority but somewhere on the list for 2024. I think we can collaborate in a discussion with Ochorocho for this

[GuySartorelli]

I agree that should be on the horizon - along with having semantic version constraints for add-ons and their dependencies.