Should this repo be forked so that development can continue?

[gerdemann]

This repository no longer appears to be actively maintained.
There are open pull requests and issues, but no current commits or responses from the maintainer side.

Should a fork be created to continue development?
Are there already active forks that are being further developed?

A discussion about this could help to make a decision.

If a fork is the solution, we could continue here:
https://github.com/openai-php-ng/client

[VincentLanglet]

I personally never got a single review in one year and half on
#287 and #429

Not even a comment.

It doesn't promote contributions

[Radiergummi]

@gerdemann if you were to fork, our company would be willing to put in development work. The current state of things is not working for us; we're depending on the OpenAI API, and have to hack the client library to accept their responses. I'm very close to forking myself, but if we could do it as a community effort, that would be great.

@gehrisandro if you would be able to chime in on this, it would be much appreciated. The maintainer team is close to the Laravel maintainers, but the level of contributions here is very different to what we've come to expect from the ecosystem. This is not an accusation. But if you provide a popular library, it would be great to either work with community contributions to get improvements into the package, or accept contributors into the maintainer team if you cannot afford the attention necessary to keep it alive. If it is a matter of funding, let's talk, that isn't the issue.
Just ignoring things causes pain to everyone involved. Right now, we'd be better off if you'd archive the repository, so the community could focus their attention elsewhere; the issues and PRs piling up (here and in the Laravel wrapper repo) don't help anyone.

Again, please don't take this as a personal attack, it really isn't, I appreciate your work, here and elsewhere. I have done my share of open source maintenance, too. I just beg your understanding that we depend on this library, and depend on it working and the maintainers responsive.

[gerdemann]

@Radiergummi Yes, I have forked the repo (openai-php-ng/client) and would also like to make a few adjustments.

If @gehrisandro can comment and the community can continue this repo, that would of course be all the better. 😄

[iBotPeaches]

I've joined to help out the maintainers. For now I'm starting small with just repository management with issues and guiding some PRs to merge. I want to stay away from larger changes at the moment as I build up trust, but like maybe both of you I've also fell dependent on this library in both hobby & work - so decided to step up and offer some help.

My rough goals at the moment:

• Merge PRs that are doc updates, type fixes, simple bug fixes.
• Investigate how people feel about the library continuing to merge things that are just fixing support with another non-OpenAI service. (see this thread)
• Augment the Laravel library to require less workarounds and just setting env values
• Look into an easier way to swap out API Keys (We have 30-40 keys for a single project to associate keys per "thing" and "env" and this library makes that incredibly difficult)
• Get support for the Responses API
• Augment the Moderation API for the multi-modality aspect (moderating images, etc)

The challenges I face:

• PRs that aged over 90d don't have workflows anymore, so I can't restart them (to trigger CI, etc)
• I don't feel comfortable merging things that for say fix an issue with Gemini, because it changes the typing that someone solely using OpenAI may have to deal with.

[Radiergummi]

That's great news. I'm happy to help out if I can and send PRs your way; just let me know what needs doing.

[iBotPeaches]

I went through both repos (Laravel/Client) and took a first pass on I think every single issue and pull request. A bit daunting, but caught up on everything.

Going to close this to not give the impression to folks peeking tracker that its abandoned. What I learned reviewing everything:

• Parity with other models (openrouter/gemini,deepseek,azure) is key. If OpenAI official SDKs work with these services, our typing is too strict to prevent it.
• If OpenAI times out, doesn't generate JSON, or gives "syntax error" - our code throwing an exception can't crash trying to throw an exception.
• Lots of new flags/properties missing on tons of APIs that we need to support
• Responses API is in progress by community and highly requested