Interested to Maintain Pico CMS

[Syed-Shahrukh-OSSRevival]

Hi,

I’m Syed Shahrukh Hussain from OSS Revival. We specialize in revitalizing and maintaining open-source projects to ensure long-term stability.

I brief about myself, I am an experienced software developer and a Debian Maintainer.

As a team, we have a cumulative 15 years of experience in {Programming Languages}, and all our developers are programming polyglots.

I have read through the issue and have some idea of the current state of the project.

I am interested in the development and maintenance of Pico CMS, ensuring it remains aligned with the project’s original vision.

Best Regards,
Syed Shahrukh Hussain.

[Croydon]

What is the motivation here? Just maintaining any random project for the sake of maintenance sounds weird at best, sketchy at worst. Did you ever hear of Pico before, do you use it for anything? What are you ideas for the future of the project?

You also wrote

15 years of experience in {Programming Languages},

so you used templates and / or AI for writing this.

[Syed-Shahrukh-OSSRevival]

What is the motivation here? Just maintaining any random project for the sake of maintenance sounds weird at best, sketchy at worst. Did you ever hear of Pico before, do you use it for anything? What are you ideas for the future of the project?

Thank you for showing interest, you have a point.

Compare this to role in a company which you aspire to join.
A standard 5 rounds including culture fit, and you are still not aware what you are going to do.
Eventually you are part of the company to do house keeping and cleaning up the backlog .

Any project small, big or very big needs an initiative. Someone has to show up everyday and fix bugs and keep things working.
This is where OSS Revival fits.

@Croydon I don't see you in the contributor list https://github.com/picocms/Pico/graphs/contributors?all=1, please share your involvement in the project?

You also wrote

15 years of experience in {Programming Languages},

so you used templates and / or AI for writing this.

Yes I do have word document as template for help.
Good pick, this was not suppose to be like it. It is neither AI or a auto gen form template. It was just a mistake. should have been just Programming Languages not specific.

[Croydon]

please share your involvement in the project?

I am just a user of Pico. I have nothing to decide here, but issues are open for discussion by anyone.

Compare this to role in a company which you aspire to join.

Humans join companies because they believe in their mission and / or because they need money. Nobody joins companies for "cleaning up the backlog".
You still haven't made your actual motivation clear, in my opinion.

[Syed-Shahrukh-OSSRevival]

The motivation is supporting existing open source projects that are unable to support themselves.

The text on Debian process below is not AI generated yet, will be in future once a bot index it.

On Debian there is a group or team called Debian QA. The purpose of this group is to maintain packages which are no longer supported by the package maintainer. There is a process for handling abandon packages, while most maintainer voluntarily change package maintainer to Debian QA and create open for adoption ticket or bug for the package.

Once the package comes to Debian QA, any contributor can fix bugs or upload the latest version of the package.

In case of dead upstream the Debian Developer working within QA team creates a ticket to drop the package for future Debian releases.

In open source the above Debian process is a luxury.

OSS Revival has salvaged open source projects few to mention:

https://github.com/Project-OSS-Revival/ssmtp
https://tracker.debian.org/pkg/ssmtp

https://github.com/Project-OSS-Revival/enca
https://tracker.debian.org/pkg/enca

https://github.com/rdiff-backup/rdiff-backup-fs
https://tracker.debian.org/pkg/rdiff-backup-fs

I am not a politician so I can't talk about future or predict it.

Usually there are external forces that influence a project direction e.g new PHP release, an outdated unmaintained dependency or a new user feature.

I hope i have addressed some of the concerns.

I am still open to answer more questions.

[PhrozenByte]

Sorry for the delay 👋

Great to hear that such projects like OSS Revival exist and people attempt to keep projects alive! ❤️

You've accumulated quite a few different kinds of projects, doing completely different things and spanning various different programming languages, all with individual challenges. I mean, it's hard to compare Pico (a CMS written in PHP) to sSMTP (a mail transfer agent written in C), or alien (a software package converter written in Perl), or rdiff-backup-fs (a FUSE filesystem for a backup software). How do you manage this complexity? I mean, it's not just about knowing all these programming languages (you said you're all polyglots, but this comes at a cost), but also about the software's individual challenges?

One thing I'm also curious about is motivation. Adopting projects simply because you believe they should continue to exist is certainly admirable. But it's also quite a commitment. Maintaining a project is one thing (i.e., the things you've mentioned, like fixing security issues and keeping it running, not really about improving the software), but actively evolving it (which IMHO also is most fun) is often driven by people who use the software themselves. Is anyone on your team already familiar with Pico, using it, or planning to use it?

Motivation aside, the issue with Pico isn't really that nobody fixed security issues (there weren't any, even though that's mostly because Pico itself is "single user" software that doesn't deal with remote user input), or that there's no compatible version of Pico (I could just merge #535 or PhrozenByte/pico and call it a day). From my perspective, the main challenge with Pico was never the codebase itself. The code is fairly stable. The real challenge is everything around it: user support, documentation, release management, maintaining backwards compatibility (which is especially hard due to Pico's history), and ultimately taking responsibility for the project and its users.

Users that don't need that can run the pico-3.0 branch or the unofficial PhrozenByte/pico fork. The code is pretty stable, it's just that Pico has a very mixed user base historically, from fellow developers to regular users. Because of that existing user base I was always quite hesitant to "just release a new version" without that "minimum guarantee of support" I've talked about many times before. Existing users tend to stay with the solution they know and trust, which is why I've always been reluctant to release major changes without having a clear plan for long-term support. It wouldn't be fair to users to make a major release, which causes them to invest hours over hours to update their website, just to learn that the project is effectively in the same maintenance state as before.

What are your short-term plans for Pico (like, your concrete next steps)? Sure, one can't predict the future, but some plan, as basic as it might be, would be great to better understand what it would mean if a project like OSS Revival would take the baton.

By the way, I'm a big fan of community involvement, so I'm very happy to see that others like @Croydon participate in the discussion. Thanks! More input is very welcome!

[Syed-Shahrukh-OSSRevival]

Sorry for the delay 👋

No worries.

Great to hear that such projects like OSS Revival exist and people attempt to keep projects alive! ❤️

Thank you, this is just grain of salt effort for the OSS community.

You've accumulated quite a few different kinds of projects, doing completely different things and spanning various different programming languages, all with individual challenges. I mean, it's hard to compare Pico (a CMS written in PHP) to sSMTP (a mail transfer agent written in C), or alien (a software package converter written in Perl), or rdiff-backup-fs (a FUSE filesystem for a backup software). How do you manage this complexity? I mean, it's not just about knowing all these programming languages (you said you're all polyglots, but this comes at a cost), but also about the software's individual challenges?

Yes this is true, I am not perfect. It is just that I pick a project and start building
knowledge within that domain. I usually start blank and with slow incremental steps get the sense of project and its direction. This is not easy but it is kind of doable, as most project don't come up with documentation. You have build you own.
As the upstream project that I maintain tied to Debian so the maintenance work is continuous.

One thing I'm also curious about is motivation. Adopting projects simply because you believe they should continue to exist is certainly admirable. But it's also quite a commitment. Maintaining a project is one thing (i.e., the things you've mentioned, like fixing security issues and keeping it running, not really about improving the software), but actively evolving it (which IMHO also is most fun) is often driven by people who use the software themselves. Is anyone on your team already familiar with Pico, using it, or planning to use it?

Yes it is commitment, I am obviously excited to see how the project evolves.
Yes the parent company of OSS Revival has some users which use pico cms.
I was motivated by my boss to look into pico cms.

Motivation aside, the issue with Pico isn't really that nobody fixed security issues (there weren't any, even though that's mostly because Pico itself is "single user" software that doesn't deal with remote user input), or that there's no compatible version of Pico (I could just merge #535 or PhrozenByte/pico and call it a day). From my perspective, the main challenge with Pico was never the codebase itself. The code is fairly stable. The real challenge is everything around it: user support, documentation, release management, maintaining backwards compatibility (which is especially hard due to Pico's history), and ultimately taking responsibility for the project and its users.

Yes this is a big under taking..
I am not a superb PHP developer. Though I have work for 7 year in professional capacity till 2014.
Though I can learn and manage the new tooling like composer.
Following the developer help in read me I tried to build pico cms 3.0 branch I got as far package manager completed with success but i am getting HTTP ERROR 500 on workspace/index.php

composer.json

composer.txt

Users that don't need that can run the pico-3.0 branch or the unofficial PhrozenByte/pico fork. The code is pretty stable, it's just that Pico has a very mixed user base historically, from fellow developers to regular users. Because of that existing user base I was always quite hesitant to "just release a new version" without that "minimum guarantee of support" I've talked about many times before. Existing users tend to stay with the solution they know and trust, which is why I've always been reluctant to release major changes without having a clear plan for long-term support. It wouldn't be fair to users to make a major release, which causes them to invest hours over hours to update their website, just to learn that the project is effectively in the same maintenance state as before.

Yes, in my opinion you can mentor me to be a maintainer.
It is going to be slow but you will have some one to give task to and I can perform it to best of my effort.
And once we reach a point where pico and me are good enough for each other you can pass the baton.

What are your short-term plans for Pico (like, your concrete next steps)? Sure, one can't predict the future, but some plan, as basic as it might be, would be great to better understand what it would mean if a project like OSS Revival would take the baton.

My immediate plans is to build development environment get familiar with project sources 3.0 branch.
Update the documentation based on my learning curve as a developer.
Look in CI/CD pipelines and the release process if can figure it out.

By the way, I'm a big fan of community involvement, so I'm very happy to see that others like @Croydon participate in the discussion. Thanks! More input is very welcome!

[PhrozenByte]

Thanks for the detailed reply, I appreciate the honesty 👍

Yes this is a big under taking..
I am not a superb PHP developer.

I don't think that's necessarily a deal-breaker. Of course, being comfortable with PHP is important for maintaining and evolving Pico in the long run. However, I don't expect anyone to become familiar with a codebase overnight, and Pico is fortunately small enough that it's possible to build that knowledge over time.

Pico is in a somewhat unique position. The codebase is largely stable and the 3.0 branch is already fairly mature. Of course, coding remains important and would become increasingly important if Pico starts actively evolving again. However, the challenges I'm most concerned about today are everything around the project itself: documentation, release management, backwards compatibility (which is closely tied to the codebase, see PicoDeprecated), user support, community interaction, and ultimately being the person who takes responsibility for the project and its users.

Following the developer help in read me I tried to build pico cms 3.0 branch

It's good to hear that you've already tried to set up a development environment and started looking into the codebase. Getting familiar with the codebase, tooling, and development workflow is definitely the right place to start. The HTTP 500 error is probably something fairly mundane that can be figured out from the webserver or PHP logs. Getting Pico running locally is usually not the hard part. It's a fairly typical Composer-based PHP project.

To be clear, there isn't really a formal process for taking over maintainership. One consequence of Pico's current state is that there isn't a huge backlog of issues to work through and there are no obvious "starter tasks" I could simply hand out. If you're genuinely interested, I'd absolutely encourage you to keep digging into Pico, get the development environment running, familiarize yourself with the codebase, documentation, release process, compatibility concerns, and everything else around it. Any contribution that happens to come up is very welcome.

At first I'd naturally review any changes before merging them. To be honest, I've been somewhat reluctant to invest significant time into driving Pico forward myself without a realistic prospect of long-term maintainership. Knowing that there is at least some genuine interest in taking on a larger role in the project certainly makes it easier to justify investing time into moving things forward again. Assuming things work out well, I'm sure we can gradually increase your responsibilities over time. My ideal scenario wouldn't be a sudden handover, but rather a gradual transition where I move into the background while remaining available whenever my historical knowledge of the project is useful.

My immediate plans is to build development environment get familiar with project sources 3.0 branch.
Update the documentation based on my learning curve as a developer.
Look in CI/CD pipelines and the release process if can figure it out.

That all sounds reasonable to me.

What I'm particularly interested in, though, is how you think about Pico from a maintainer's perspective rather than a developer's perspective. So let me turn the question around a little: if you imagine yourself already being Pico's maintainer, how would you approach an eventual Pico 3.0 release?

For example:

• What would you want to verify before calling it release-ready?
• How would you approach backwards compatibility and migration guidance?
• What kind of support expectations would you set for users?
• What would your plans for the project look like during the first 6-12 months after a release?

I'm not looking for a perfect roadmap here. Nobody can predict the future. I'm mostly interested in understanding how you think about maintainership and what taking the baton would mean to you in practice.

One other thing that caught my attention:

I was motivated by my boss to look into pico cms.

It's great that your employer has an interest in Pico and that this was the initial motivation. It's certainly a valid starting point. At the same time, maintainership is often a multi-year commitment, sometimes outlasting the original business reason for getting involved. I'd therefore be curious to hear a bit more about your own personal interest in Pico and what would motivate you to stay involved in the project over the long term. Open source projects usually survive because somebody genuinely cares about them. What is it about Pico that makes you want to spend your own time on it?

Looking forward to hearing your thoughts ❤️

[Syed-Shahrukh-OSSRevival]

Sorry, getting answers were not possible immediately so i took time to understand scheme of things at pico e.g. existing github workflows.
HTTP ERROR 500 was due to missing php8.4-xml on a nginx setup.
Packages dependency:

php-common/stable,stable,stable,stable,now 2:96 all [installed,automatic]
php-fpm/stable,stable,stable,stable,now 2:8.4+96 all [installed]
php8.4-cli/stable-security,now 8.4.21-1~deb13u1 amd64 [installed]
php8.4-common/stable-security,now 8.4.21-1~deb13u1 amd64 [installed]
php8.4-fpm/stable-security,now 8.4.21-1~deb13u1 amd64 [installed]
php8.4-mbstring/stable-security,now 8.4.21-1~deb13u1 amd64 [installed]
php8.4-opcache/stable-security,now 8.4.21-1~deb13u1 amd64 [installed,automatic]
php8.4-readline/stable-security,now 8.4.21-1~deb13u1 amd64 [installed,automatic]
php8.4-xml/stable-security,now 8.4.21-1~deb13u1 amd64 [installed]

What I'm particularly interested in, though, is how you think about Pico from a maintainer's perspective rather than a developer's perspective. So let me turn the question around a little: if you imagine yourself already being Pico's maintainer, how would you approach an eventual Pico 3.0 release?

For example:

• What would you want to verify before calling it release-ready?
• How would you approach backwards compatibility and migration guidance?

I need to build enough data or use cases to test the application, to ensure support for older version of pico installation after update. So with any future releases these scenarios can be tested with different PHP versions.
The steps given can be considered as a 6 month beyond plan:
a. Add unit and function testing framework to pico.
b. Build tests that cover functional and unit aspects.
c. In past i did BDD ed user testing, so in present scenario it fit well with plugins and its user interaction or User Acceptance Testing. There is a Gerkin clone for PHP too.
d. Setup code coverage pipeline based on unit tests.

• What kind of support expectations would you set for users?

1. Active engagement of tickets like labeling, and most likely ask community help e.g. first good issue/help needed labels.
2. Best effort timely fixing critical issues and start planning for minor release.

• What would your plans for the project look like during the first 6-12 months after a release?

I have tried to build a plan for 6+ months above, which will cover current and future needs of pico.

I'm not looking for a perfect roadmap here. Nobody can predict the future. I'm mostly interested in understanding how you think about maintainership and what taking the baton would mean to you in practice.

Usually when there is some activity(yearly or monthly releases) within a project, people tend to fix issue first rather than reporting it e.g patches or PR's.
So a maintainer job is to navigate through this PR and use best judgement what to include or reject.
As most git PR's are just created by users to build profile reputation rather than project involvement and have no interest in following up with the PR too. While it is maintainer responsibility to review the PR and discuss it if needed.

One other thing that caught my attention:

I was motivated by my boss to look into pico cms.

It's great that your employer has an interest in Pico and that this was the initial motivation. It's certainly a valid starting point. At the same time, maintainership is often a multi-year commitment, sometimes outlasting the original business reason for getting involved. I'd therefore be curious to hear a bit more about your own personal interest in Pico and what would motivate you to stay involved in the project over the long term. Open source projects usually survive because somebody genuinely cares about them. What is it about Pico that makes you want to spend your own time on it?

Concerning Project OSS Revival, i will be working within the project hopefully long time maybe in different capacity if scenario changes relocation etc..
Beyond Project OSS Revival, if I have no health issues I am committed to work within the OSS domain, taking ownership of what I love to do.

Past week I have explored/enjoyed pico simplicity. I enjoy working in PHP and a have history going back year 2000 when web and PHP was very simple too.
I have been using ruby based Jekyll for my own website https://discreteworks.com, I took this path just because github support it. Later to realize in limited capacity. So i am hosting it locally. I am thinking of moving it to pico. In this way i will have a hands on use case where pico can be extended if needed.

Looking forward to hearing your thoughts ❤️

Thank you for taking time to read through my thoughts ❤️.

It was a pleasure revisiting my capacity and answering the questions to the best of my knowledge.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! 👍

[PhrozenByte]

Sorry for the late reply @Syed-Shahrukh-OSSRevival. I haven't forgotten about this, but I'm currently completely tied up with some personal matters and haven't had the time to look into it properly. I'll get back to you towards the end of the week.

[PhrozenByte]

Sorry again for the delay! It's been almost two weeks now… I had some personal matters to take care of, so I simply didn't have the time to give this discussion the attention it deserves. Thanks for your patience ❤️

First of all, thank you again for taking the time to answer so thoughtfully. I really appreciate the openness throughout this discussion. I also appreciate that you actually took the time to get Pico running locally instead of just talking about it. That's exactly the kind of initiative I'd hope to see 👍

As said earlier, I like the idea of approaching this as a gradual transition rather than a sudden handover. I don't think maintainership is something one can really evaluate through theoretical discussions alone. At some point it simply becomes a matter of working together on the project, building familiarity with both the codebase and the community, and seeing whether it turns out to be a good fit for everyone involved. I'm optimistic about how this could work out. So, I think the next step is simply to start and see where it leads, WDYT?

Concerning Project OSS Revival, i will be working within the project hopefully long time maybe in different capacity if scenario changes relocation etc..
Beyond Project OSS Revival, if I have no health issues I am committed to work within the OSS domain, taking ownership of what I love to do.

Thanks! It's reassuring to hear that you see yourself staying involved with open source over the long term regardless of your exact role with your employer.

I need to build enough data or use cases to test the application, to ensure support for older version of pico installation after update.

That overall direction makes sense to me. Thinking in terms of real-world usage scenarios, backwards compatibility and how existing installations behave across updates has always been one of the more important aspects for Pico. The same applies to your ideas around testing, CI/CD and a more structured release and quality process in general. I think this is a reasonable direction for a project like Pico.

I am thinking of moving it to pico. In this way i will have a hands on use case where pico can be extended if needed.

I actually think that's a great idea. One of the best ways to get to know a project is by using it yourself.

Funnily enough, Pico's own website has a very similar story. Despite being Pico's website, it actually isn't powered by Pico at all. It's built with Jekyll due to the same reasons - because it's hosted on GitHub Pages. See picocms/picocms.github.io.

That got me thinking:

One thing that has been on my mental wishlist for - like, always - is migrating the Pico website itself from Jekyll to Pico. Pico can also be used as a static site generator (for example by combining it with curl during the build process), so there isn't really a technical reason for the website not to dogfood Pico.

I think this would actually make a very nice project, because it naturally touches many of the areas we've been talking about. You'd get hands-on experience with Pico itself, complex themes, 3rd-party plugins (which naturally also involves backwards compatibility, therefore also PicoDeprecated), the docs, the CI pipeline, and the overall developer experience. It also has a well-defined scope. It's large enough to touch many different aspects of the project, but small enough that it can be tackled incrementally without having to make release-critical decisions right away. At the same time, improving the docs whenever you run into rough edges would directly benefit future contributors and users.

Unlike a purely theoretical discussion about maintainership, this would also produce something tangible that is genuinely useful for the project - and a very good starting point for potentially taking on maintainership responsibilities later on. It would also give us a chance to work together on something real and get a feeling for how things work in practice, not just discussing hypothetical scenarios.

If that sounds interesting to you, I'd be very happy to support you along the way whenever historical context or project-specific knowledge is helpful. I'd intentionally leave most of the implementation decisions to you. I'd mainly be there to provide historical context, explain why certain things evolved the way they did, and review your changes, while gradually giving you more room as you become familiar with the project.

What do you think?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! 👍