Fund PDFParser: Thoughts and decisions

[unixnut]

To our community:

Everyone is invited to comment on this topic, no matter if its critic or suggestions.

---

I feel like a substantial project like PdfParser takes a lot of time to maintain and that it's worth supporting. All work so far has mostly been on a volunteer basis as far as I'm aware. Perhaps it's time to consider possibilities for how contributors could receive some financial reward for their work, without taking away the project's essential nature as a volunteer effort.

I'm hoping to do professional Open Source work (in addition to my consulting work and hobby projects). This kind of "paid volunteering" would make it practical for me to devote time to PdfParser. Should we set up TideLift or a related centralised sponsorship service, or financial hosting platform such as OpenCollective?

We could also link to active contributors' individual funding page such as GitHub Sponsors, Patreon, etc.

A third option for people to receive funding to work on this project is through bug bounties and sponsorship of specific features. This would benefit from some coordination including a triage and/or voting process, I think.

I can help the existing maintainers work together to establish a set of recommendations, with input from the community, about how others can join the project as a contributor. (Some related information at #286.) The aim of this suggestion is to avoid the scenario where someone says they will contribute in the hopes of getting funding, but then does not put in work after being approved. If someone gets busy elsewhere, there should be a way for them to state that they're taking a break from the project. It's worth noting that these "new contributor guidelines" should apply to people joining the project regardless of whether they want to do funded work.

I'd like for someone to have an ongoing record of working on PdfParser before they are listed as an active contributor. Extra requirements should apply if they wish to become a core contributor and receive a share of centralised funding from project sponsors. An even higher standard should be applied when considering someone as a possible maintainer (who can accept PRs and approve people's contributor level, etc.).

Another suggestion is that this project should have a Code of Conduct that applies to anyone submitting issues, making comments, creating PRs, etc. This is to help ensure fairness and community safety.

[unixnut]

@j0k3r As you are a maintainer, I wanted to make sure you saw this so you have the opportunity to comment if you want.

[j0k3r]

Well I'm more than a ghost maintainer than an active maintainer itself :)

But I agree it could be a good idea to dedicate some work on some features/bugs if this can be fund in some ways. Everything towards that goal is good idea.

[k00ni]

That is an important topic and I support the idea from @unixnut.

Why we need this

My observation is, after almost 4 years as a co-maintainer, that there are many community contributions (which is great) but almost no work from the author @smalot anymore. Its great that we have his trust and he has its reasons, but in the end it means that we as a community are on our own for an unforeseeable future. This library is used in many projects, most likely a significant percent with money involved. Therefore a stable basement for the future is needed and unfortunately @j0k3r and I can't fill it in a way it might be required sometimes.

The following points are important to consider

1. Earning and distributing money is a very sensitive topic, so we should find a transparent solution which provides enough incentives for developers to contribute/help out but also gives sponsors some security. My knowledge in project/contributor funding is very limited though, so further information are appreciated.
2. As far as I see @j0k3r and I as maintainers don't have extend access to settings of this repository. We can manage issues and pull requests, merge PRs, but are not able to change texts on the front page of the repository for instance. New content about the funding therefore must be located in a file.
3. @j0k3r its good to see you approve at least the general direction. Our community is very quiet when it comes to decisions, so I assume it is about us two in the end to decide.

Lets get to work

To me its not clear when or even if @smalot will ever return or participate here, so creating a sponsoring service in his or the projects name is at least difficult/delicate in my opinion. Therefore I suggest to start small and scale up. That means we should start with people like you @unixnut who are interested in helping out and build/provide an appropriate infrastructure. You provided three options how to implement this, they are a good starting point.

I suggest the following steps to get this going:

1. Create a new file in the root folder which contains all relevant information about sponsoring/supporting. Name suggestions: SUPPORT.md or SPONSORING.md (called "sponsoring-program-file" for now). The file should reflect the current situation and also contains a list of people who are interested in contributing to this project in exchange for a sponsoring. Everybody interested in participating can create a pull request to add the own profile to the list.
2. Extend README.md to inform the community/users about the new sponsoring program with link to the sponsoring-program-file
3. Contributors are free to use whatever they want for sponsoring: Patreon, Github, TideLift, ... . Is it reasonable before adding them that all sponsoring links are present in their Github profiles?
4. Add further issue templates: one for users who are interested in sponsoring someone to kill a certain bug or implement a new functionality. And a general one.
5. @unixnut you already proposed some rules. Please add these to the sponsoring-program-file too. This way our processes are transparent and people can check for themselves. I would add here: Its between the sponsor and the developer when it comes to sponsoring a bug fix, for instance. We maintainer are only taking care of the related pull request and communication around it, but are not involved or even responsible for any action outside of this repository. I can imagine that this might pose some uncertainty on the program.

This list might be incomplete and is only meant as a suggestion. There might be further things to discuss before we move this issue forward. I wanna outline again that everyone is welcomed to propose ideas here or even create pull requests to suggest file content.

[j0k3r]

Maybe it's the right time to move the repo to an organization instead of keeping it in @smalot. Something like https://github.com/phppdfparser/pdfparser (yeah because https://github.com/pdfparser is already in use).

So it'll be easier to manage the whole project/repo as admin.

[unixnut]

Thanks @k00ni and @j0k3r for your feedback. I have some comments.

Firstly, TideLift sponsors repos not individuals. Worth looking at their rules but this would be for when there are a greater number of maintainers, I think. There are agreements and such to sign.

With so few maintainers currently, rather than a standalone organisation, perhaps it would be a better idea to become part of the The League of Extraordinary Packages (formerly known as the PHP League)?

[unixnut]

Tomas Votruba has a great article on how to deprecate a PHP package but his action steps (see "3 Steps To Perform Safe Deprecation" section) can also apply to this case.

Would it have to be @smalot who transfers the GitHub repo and clicks the Abandon button in the Packagist web console? See article above for how Composer then suggests the replacement when someone accidentally installs the original package.

Also, I suggest that @smalot gets a share of future funding as a thank you for writing this package in the first place.

[k00ni]

There is so much work/thinking involved when moving this repository, not to mention informing our community. I don't see the need for this step (yet) and I don't have the time to (help) organize it. If you guys still think this is the best move right now please open a new issue and we can have a discussion there. This issue should be solely about project funding.

That being said, I would rather start small and evaluate how it goes. @unixnut how is it going and what are your next steps? Speaking of evaluating, do you guys have access to the Insights > Traffic area here (shows number of Git clones, visitors etc.)?

[j0k3r]

I was thinking of moving to an existing organization (like FriendOfPHP) but won't this be incompatible about providing funding for the project?

Speaking of evaluating, do you guys have access to the Insights > Traffic area here (shows number of Git clones, visitors etc.)?

Yep.

[unixnut]

@unixnut how is it going and what are your next steps?

Please await my PR by the dawn of the third day. 😎😆

[unixnut]

Turns out that GitHub has built-support for showing that a repo is sponsored.
Go to the settings page and find the Sponsorships option. It says this:

Display a "Sponsor" button
Add links to GitHub Sponsors or third-party methods your repository accepts for financial contributions to your project.

Does anyone think this would be relevant?

[k00ni]

At least I have no access to the settings page of this repository and I assume @j0k3r doesn't have it too.

[j0k3r]

@k00ni you're right, I don't have access either.