In a new post to his site Tomas Votruba has shared a list of five things that he, as an open source package maintainer, had heard before getting started.

I wasn't always confident while making public every single line of PHP code I write. I had to take many blind paths, spend a night full of stress coding in unknown waters and make a lot of over-complicated code that backfired to me months later.

They say "experience cannot be passed and it must be experienced" and I agree with that, but still there are some shortcuts that would speed-up my path to joyful open-source coding I have today. Here are 5 of them.

He then shares his suggestions, each with a brief summary explaining what it means and how you can apply it:

1. Be Open to Change any Package
2. Don't Keep Every feature You Have
3. Lock to LTS, Maintained Dependencies and green PHP
4. All You Need to Maintain is 1 Repository
5. Don't Take Advise as Granted, Experiment for Yourself

He includes some of his own backstory in several of the posts about his own development work and how he found out some of these "the hard way".

In a post to his site Brandon Savage shares some of his thoughts about PHP package development and suggests how to figure out what versions of the PHP language it should support.

Everybody likes “the new hotness.” [...] Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.

[...] A new version of PHP can pose challenges to open source package maintainers. There are questions, like what is the minimum version we will support and how soon can we take advantage of the new features we’ve been waiting on? I want to offer up some thoughts, both as a package maintainer and a user of many open source packages.

He goes on to suggest that package authors should support down to the last currently supported version of the language (v5.6 at the time of this post). This allows users of the package that may be restricted and don't have the "new hotness" to keep using the package. He points out that this doesn't mean that you shouldn't use new features, just that older versions should be supported along with the newer ones for those depending on the package. He makes three suggestions as to how he thinks package maintainers should approach the issue:

• maintainers should feel comfortable in bumping up the requirement to the latest (in a major release)
• maintainers should also ensure that the support is still there for older versions that can't use the newer features
• maintainers should bump up this minimum version when it falls out of active support

Supporting old versions of a language isn’t fun and isn’t glamorous. But it’s important. It’s important because there’a segment of the population who can’t upgrade yet. It’s important to make components accessible to a larger, broader audience who is struggling to find best practices and use modern packages. And it’s important for those users who are tied to a legacy version, and are struggling to get upgraded. But it’s the right thing to do for the community.

In a new post to his site Alex Bilbie has started the search for a new maintainer for the league/oauth2-server package citing the lack of time on his part to give the project the time it needs to flourish.

A little over five years ago I pushed the league/oauth2-server. The project has been downloaded over 2.5 million times, has more than 3000 Github stars and has been contributed to by 77 awesome people across some 2000 commits.

Last year when I became self-employed I had intentions that I’d have more time to dedicate towards open source projects but reality worked out slightly differently and I’ve had one of the busiest (and best) years of my life.

He also points out that, besides the lack of time to work on the project, he also doesn't actively use the project himself and wants to find a maintainer that "is/are really impassioned by the project, want to advance the project (for example implement OpenID support) and are willing to devote time to answering support requests and review pull requests."

If this interests you and you'd like to see the project move forward, the post includes his contact information for you to reach out.