Consider rewording the ESP to make more partners eligible #1371
Comments
|
It's worth noting that the ESP was formed because of HeroDevs' interest - are there any companies (including Tidelift) that have an expressed interest in some kind of partnership? |
This is a catch 22 – if worded like the current program then I think few other partners would find themselves a match for it and thus naturally not express interest, at least not interest in that program specifically I think a better question is:
|
I don't think that's a real concern. If anything, ESP shows that the foundation is interested in pursuing novel approaches to open source sustainability and puts it on the radar of organizations who are looking for partners in that space. Folks running business are business-savvy enough to know that the terms of partnerships are negotiable and that if there's a will to collaborate, there's a good chance something can be worked out. Additionally, this is a small world where folks know each other. If the goal is to increase partnerships, it'll be a lot more effective to reach out to potential partners and have conversations than to open-up hypothetical terms that we believe could be attractive to some organizations. From a biz-dev perspective, I think the right decision at this point is to focus on making the existing partnerships successful first, and possibly expending to different types of partnership in the future if the existing ones turn out to be successful. Additionally, reviewing this policy would need to get both CPC and Board approval and folks would rightfully ask for the reason to burn cycles on modifying the existing policy without a concrete partner to base the changes on. I don't think we should pursue this further until it enables a new partnership and the timing is write from the foundation's perspective to do so. |
|
That's like saying the lack of an ESP entirely was a catch 22. How can we reword a program when we have no idea who, if anyone, is interested? We of course should be willing to make whatever changes are needed to bring on more beneficial partners, but such partners need to affirmatively indicate interest so we can have a conversation. |
|
Let me rephrase and simplify as it seems like we missed the main question: Were there any reasons at all to limit the program to EOL / outdated software other than the fact that it was what @ljharb / HeroDevs pitched? |
|
We just didn’t have that conversation because no one showed up with a concrete and credible partnership proposal around something like this. I believe the business model would be different, as would the tradeoffs. Again, there’s no point trying to figure out what something like this would look like in a vacuum. |
|
That said, we could add somewhere in this policy a sentence suggesting that the foundation is always open to novel solutions to improve open source sustainability and that folks who have concrete partnership proposals are welcomed to reach out. |
Some discussion and consideration must surely have been had when this was made into the Ecosystem Sustainability Program rather than just a OpenJSF / HeroDevs partnership? Going beyond simply announcing a partnership with HeroDevs to launch a program implies – at least to me – that there’s been an idea about who the other possible actors in the program could be? And in doing so a discussion around the scope of the program and the limits / scope of it? Else, why was it launched as a program rather than a simple OpenJSF / HeroDevs partnership? |
|
My understanding is that nonprofits are not permitted to have exclusive partnerships, so it was thus launched as a program to ensure the possibility exists of additional partners - although none were identified. |
If anything this just makes it more problematic. I'm not claiming that this is the case: But any doubts whether the ESP was worded like it is by HeroDevs to circumvent that ban on exclusive partnerships – such doubts would reflect poorly on the OpenJSF. Your very comment @ljharb shows that this issue was a concern known to HeroDevs and no comment here from anyone else involved from the OpenJSF side serves to show that any care was taken to ensure that the program didn't become an exclusive partnership in everything but name. This is a bit disappointing – especially as all involved parties was well aware about the conflict of interest that's been present from the start with @ljharb's involvement in both HeroDevs and OpenJSF. With that in mind I would have expected extra much care to have been taken to ensure that there can be no doubt on whether this is a program open for all or one tailored for HeroDevs and no-one else. I'm not making accusations here, I'm simply highlighting that there can exist doubts and that mere possibility reflects badly on OpenJSF. I think the OpenJSF should consider doubling down and ensuring that no doubts can be had here. With that said I will leave this issue and let others decide if it should be closed or worked upon further – its clear that its not somewhere where I can make productive contributions. |
|
There can always exist doubts - the program is in no way an exclusive partnership, and any efforts were to ensure that it didn't falsely imply that. Again, if any company wants to partner with OpenJS, they should step forward, and if they don't fit the current terms of the ESP, we should adjust them as needed - but until one shows up, this entire issue reads like FUD to me, and indeed looks like an accusation. |
These are the very efforts that I asked for initially – can you elaborate? |
|
We had extensive discussions in the board and the CPC. I wasn't part of the discussions between HeroDevs and OpenJS specifically to avoid (or minimize) conflicts of interest, so I'm not sure where that specific phrasing regarding EOL versions came from, but my assumption is that since no other companies have expressed interest, it just didn't occur to anyone to go beyond that. Do you know of any companies that want to parter with OpenJS and aren't eligible based on the current ESP text? If so, let's expand them to include those companies. But, in the absence of one, I'm confused why it matters. |
It matters because of perception and it matters when doing outreach and trying to convince possible partners to join. But anyhow, I find the handling of this disappointing and unwelcome so I will unsubscribe from this issue now. Feel free to close if you believe it has no merit. |
|
To be frank, it sounds like you're upset that this new and innovative program that nobody's ever attempted before isn't accounting for possibilities nobody's suggested or thought of. If there's a company you're doing outreach to on your own without discussing it with anyone else in OpenJS, then I'd invite you to seek counsel first. If there's something OpenJS, or the ESP, can do to make it more amenable/welcome to new partners, then strategically, we should be apprised of that possibility before attempting any outreach, so we can set everyone up for success. |
Part of the requirements voiced at both the CPC and Board level was that this wouldn't be exclusive. @voxpelli: I'm happy to address questions about this in a call as I think we're talking past each other in this issue. |
It's not just me that may wonder the things I raised here. I think I have expressed them clearly and will leave you all to handle it as you prefer. I have no intention or interest to pursue any of it further – I feel my time is better spent elsewhere and will again unsubscribe to this issue. |
|
Seems like I am late to the party. Thank you all for sharing your perspectives on this important topic. IMO, based on the current discussion, the best way to continue discussing this is to switch to the meeting format and consolidate conclusions and action items from there. I believe it would be beneficial to bring this discussion to the Sustainability Collaboration Space as part of our upcoming agenda, as it is the shiny new collab space dedicated to sustainability 😎. This would allow us to collectively review the current proposal and consider any necessary revisions to make it more inclusive and effective for potential partners. I appreciate everyone's insights and look forward to working together on this. Some personal notes for the meeting: This will help me bring the topic to the meeting, but feel free to add your own thoughts 👍
Note: React with 🚀 if you also think that we can migrate this issue to the sustainability collab repository. |
|
I'm a huge +1 for moving this discussion to the sustainability collab space. I note however that any editorial changes to the policy itself will require CPC approval, and substantial changes will require board approval. I also want to add here that actively seeking new partnerships is an operational decision that belongs to the foundation's ED (@rginn) with strategic direction from the board. OpenJS is a small foundation and its resources aren't extensible. There's an opportunity cost to everything, and it would seem wise to pursue the current plan of first assessing the success of this initial initiative before attempting to broaden it. |
|
As somebody that was part of the decision making progress of that lead to the ESP, I can clarify why the statement is limited to EOL.
The reason why only EOLs are allowed for this is that we wanted to be conservative and allow the current maintainers of the project to be involved. If we allowed a 3rd party to provide official support for our project, what would that entail? Either they take over the project from the maintainers (hardly possible), or they won't be able to guarantee timely bug fixes for their clients, breaking the SLA clauses in their contracts, or they are allowed to create a |
|
Right, @mcollina! That said, there might be business models that provide support beyond EOLs that are well-aligned with the foundation's mission. It's just not the job of the foundation to come up with them. |
|
@tobie I 100% agree. |
|
Hey friends, weighing in now since I just returned from vacation. I have had conversations with other potential partners. This is non-exclusive. However, I want to give credit to the leadership team at HeroDevs for this innovative and generous program idea, and our legal team at OpenJS and our Board who worked through all the details of this specific program (many discussed on this thread) to ensure it aligns with our mission and nonprofit status. An important note on our partner programs: as a nonprofit, contributions must be made for the greater good of the project and ecosystem. Donations cannot benefit an individual donor. We are totally open to other ideas that would help raise funds to underwrite the myriad of activities required to sustain our projects. We would work with our legal team, Board and CPC to structure it accordingly. We can discuss further in our Sustainability Collab Space. |
|
The ESP claims to be non-exclusive but de facto it seems to be a program which only HeroDevs is matching the conditions for participation. First of all, an ESP partner has to be a platinum or gold member of the openjsf, as stated on https://openjsf.org/ecosystem-sustainability-program and not in the markdown file. I highly doubt that microsoft, google or the german souvereign tech fund will participate in the ESP. So there is a glass ceiling. Either the md file should be corrected and state that only a gold and platinum member can be partner, or the webiste needs to be corrected. Then it is not clear how much a company has to pay to get exclusive access to the HeroDevs artifact server? What prevents HeroDevs to increase the costs over time in an unfair way? This year it costs you 100 In the markdown file you wrote Can you please clarify in the md file, that only on the version support page the referral link, or that it has to be on every page of the website? Also I kind of find it strange, that Open Source becomes Closed Source. Under which license will the "supported" forks of HeroDevs be? Do I need to uninstall the packages from HeroDevs, if I cancel the subscription to the ESP of HeroDevs? Can I share the package of the herodevs artifact server again publicly on npm? I mean, If HeroDevs "only" backports PRs of a project, than they have no IP anyway. E.g. I license my code under MIT in an OPenSource Project. HeroDevs backports it and sells it under a proprietary license. But I never waived my copyrights. So the MIT license still applies, no matter what HeroDevs is claiming the license will be. Can a project pair up with multiple partners? This should be clarified too. Also currently I can see on a popular project, that they advertise for the ESP by HeroDevs, but there is NO documentation if HeroDevs has any prepared fork of the EOL versions. Atleast I would expect, that a partner has the obligation to document which security issues were fixed in the said EOL versions. Currently a partner could just sell the ESP by creating FUD, and a customer could not determine if there is any(!) benefit by signing up for the ESP. Here we should add some documentation obligations for the partner. Once it was argued to me that the ESP Partners have business insurance, so if an EOL version is messed up, they cover for any damages. But our MIT license clearly states: use at your own risk. But there is no hint on a business insurance the partner should have. And if they need a business insurance, then this implicates that the software is not relicensed under MIT?! This "new and innovative program that nobody's ever attempted before " is for me just a disguised vendor lock. |
Arguably no. I invite all sort of other companies to do it.
A company has to be a Gold or Platinum member to have the trademark license for the ESP. There is no glass ceiling, but a clear definition of commitment from said company. Administering and setting those deals up have measurable costs, and this foundation does not operate out of thin air. We might consider lowering the requirement to silver for next year if so is the wish of the projects. It’s better to be prudent and get things done step-by-step.
How does this matter?
Yes, but they have no requirement to share. A few companies are already doing this (I can share a short list in private if you want). The ESP allows a way for companies to market this effectively to the public and contribute back to the projects.
How does it matter and why are you asking this here? Ask them!
I’m not a lawyer and a formal response can be crafted by a lawyer in case this is a question that the CPC wants answered. My understanding is that the license of your commits still applies, but there might be proprietary parts in there. In the case of Node.js the hardest parts are:
This is actually very costly and serve a need of the industry. Note that no one stops any company to create Foo.js which is a fork of Node.js doing all the above. The ESP allows for a way to market this.
Yes they 100% can. It’s up to their governance to decide.
Insurance is absolutely not connected to OSS licenses, in the same way you can buy a car insurance from any vendor and not from the car producer.
How come? It’s literally open for every company to joinz |
|
We’re excited with the ESP. We spent considerable time working through the many details with our OpenJS Board and legal teams. The project was thoroughly reviewed by the CPC before it was approved. ESP is entirely voluntary. Each foundation project is entirely free to decide whether to opt in to it or ignore it. It’s only if the project decides to opt in that ESP partners may use the project’s trademarks. Multiple projects have decided that the ESP is a good fit for them and have been onboarded already. Others are coming soon. ESP might not be a good fit for every project or every open source community, and that’s perfectly fine. Every project gets to decide what is right for itself. If you’re still undecided or have questions that weren’t answered in our OpenJS maintainer town hall and project meetings that we organized, please feel free to reach out. We’ll continue to communicate about the program. We will look to add an FAQ section to our website, in addition to future blogs. We’ll also collect feedback and review the program as it’s implemented in the upcoming year and adjust if needed. The sustainability of JavaScript communities is a top priority at OpenJS. To reiterate, we are totally open to other ideas that would help raise funds to underwrite the myriad of activities required to sustain our projects. We would work with our legal team, Board and CPC to structure it accordingly. |
|
I've just read all of this and my primary comment, as the general counsel of an entity that provides economic support to many OpenJS-adjacent maintainers, is that this is all extremely confusing (and/or entirely vague). I would strongly urge y'all to improve your explanation of what's going on. Among other questions I have:
Also noting that this is not an academic question for us since we do have maintainers who are both supported by Tidelift and affiliated with OpenJS, and they're sharing concerns with us, especially about exclusivity. So anything I can do to be helpful here, just let me know. edited to add 2024-10-15: question (5) and note about concrete nature of the problem |
I asked in Slack if anyone remembered why the Ecosystem Sustainability Program became limited to partners that focuses on EOL versions:
cross-project-council/project-resources/ESP/ECOSYSTEM_SUSTAINABILITY_PROGRAM.md
Line 24 in 862583f
The one reply I got, from @mhdawson, was:
I personally think that the current limitation to partners who focuses on EOL versions excludes companies that could otherwise be a great fit for the program, and might make some not even reach out to discuss the program.
Eg. Tidelift is a good example – its very much focused on Ecosystem Sustainability and its in use by quite a few OpenJSF projects, but it does not qualify for the Ecosystem Sustainability Program currently, as Tidelift does not focus on EOL-versions specifically but rather on helping ensure maintainers can keep all versions secure.
All in all:
If there's no active intent in excluding non-EOL focused companies, then the ESP-program should be rewritten so that more companies than essentially just HeroDevs can qualify (I'm not aware of any other company that has opted for a business model focused specifically on EOL-version)
The text was updated successfully, but these errors were encountered: