We’d be supportive of something like this. I think the easiest way to start would be manually – you could say “if you have a Tidelift Subscription, let me know, and I’ll give you some extra voting points” – we’d be happy to verify any users manually, if you email us and ask. That way we could test whether you get any interest… I think an OAuth API is a great idea to scale it up, but maybe not a blocker for us to try it out?
btw, curious whether anyone else reading this has thought about similar experiments?
As a Lifter, I, too, would like to be made aware of Subscribers engaging with me, or my projects.
Knowing when a Subscriber has filed an issue, or engaged in an existing issue (comments, reactions, pull requests, backlinks, etc.), provides insight into pain points experienced by that Subscriber, or where they could benefit by the introduction of additional functionality to that project.
While I’m not, to my knowledge, obligated to introduce enhancements on request of a Subscriber, I do want to ensure I’m prioritizing issues relevant to the Subscriber. I believe the whole reason they are engaging with my project is because the cost-benefit works out for the change to be made to my project, instead of, perhaps, an internal fork.
If I’m not able to address those needs in a timely manner, engaging with my project may no longer be in the Subscribers best interest.
On a related note, the company I work for has a strict policy against publicly disclosing the software we consume internally (though exceptions are made when contributing back to Open Source). How could my company, if we were a Subscriber, ensure our employees were able to safely disclose our use of an Open Source project only to Tidelift Lifters in adherence to our company policies?
That’s one of the kind of tricky things here - we’ve run into two ways companies seems to approach things, some as you say have a policy against disclosing what they use, while some others actively advertise it (as a recruiting thing for example). So we’d want to respect both of those approaches.
Something we’re happy to do for subscribers right away is act as an anonymizing intermediary - if a subscriber wanted to file an issue without disclosing identity, we could file it for them, no problem.
Since you’ve been on both sides of this, any thoughts about the ideal way for it to work, maybe thinking about something more software-based instead of manual?
That’s an appreciated offer, and as a Lifter, I hope Subscribers will take y’all up on the offer so they are able to routinely engage with Lifters to address their needs.
Please let me convey a few thoughts on what I am/was looking for to help me maintain a view of what my Subscriber-based users need.
I originally dropped in on this thread because of @kylekatarnls comment, It seems fair to me to pay attention to users who pay for it.. That comment rung true for me.
Unfortunately, most of my projects are feature complete. They’re small tools or CLIs that do one thing, and do it well, never exceeding their original problem scope. So I don’t have many projects with opportunities for feature growth, limiting chances for Subscribers to vote on feature prioritization.
Most of my projects just need to address the occasional compatibility issue with an underlying API (services, or CLI tools). For the community I support, that means receiving requests to support a new product API, or, in one unfortunate moment, reverting a change because I broke my CLI when I switched to Git 2.x, whereas several Enterprise companies were still operating RHEL with Git 1.8.
What has helped me in the past has been quick discovery of issues effecting Enterprise users, with a rough idea of the extent of the disruption. From there, I can allocate the limited I time I have to addressing the greatest need. It feels very similar to what @kylekatarnls was discussing, except I feel timeliness is a little more important. Therefore, while I really appreciate the offer to validate Subscribers on a Lifters’s behalf, I worry the latency of the verification process may be too great.
Another wish is to have the ability to re-evaluate priorities of an older tasks. I’d like to account for the ever changing usage of my projects by Enterprises, and their shifting priorities. That kind of applies to issues filed by Tidelift on behalf of Subscribers. Who would curate those issues to ensure they’re still relevant to a Subscriber?
Here I am, I created a GitHub issue first to test if I can have enough participants to such community brainstorming:
For now, I just asked users to let me know if they have a Tidelift subscription. If there is enough ideas and feedback, I will install a PHPBack/UserVoice or some suggestion voting system to handle it more officially.
Sorry for people waiting for the result of this experiment, it’s a flop. Maybe because answering an issue is not a convenient way to vote, but on the other hand, I did not want to host and deploy a tool dedicated to voting if I’m note sure to get participants.
The issue is now the road-map with expected dates of next milestones. But the issue is not locked, users can argue for priority changes.
An other idea to recognize Tidelift subscribers on GitHub would be to use an organization. Tidelift could create a new one that would only accept users related to a Tidelift subscription. This way, the user would not need to announce he has a subscription, we could just check quickly his/her profile and see if he/she belongs the org.
Is it really true that some companies don’t want the author of XYZ to know they are using XYZ? I understand they might not want the public to know, but why wouldn’t they want the author to know?
There are a number of ways that open source doesn’t follow the typical “customer/provider” relationship model, but this isn’t one of them, is it? Wouldn’t it serve everyone’s interests for a package to know who its users (customers) were?
I’m not sure what organizations’ full rationale for secrecy is (sometimes organizations’ policies are more emergent accident than rationale-having anyway). It’s something we may be able to learn more about over time.
It’s possible they’ve never seen “share with maintainer without making it public” as an option. Perhaps we could create that option…
On our website, we list all persons and organizations that openly support Project Lombok.
If subscribers are willing, or even requesting. to disclose this information, I can imagine we could show their logo and link to their website on our supporters page We could put them in a separate “Via Tidelift” category, or enrich their logos with a “via Tidelift” overlay icon.
That would require those subscribers to provide their logo, website and consent.
We would also need a Tidelift provided API to embed that in our website.