You keep linking to the Registry pricing, and I need to point out that is separate from the IDE offering. The hosted Registry is analogous to Microsoft's VSCode Extension Marketplace: VSCode and derivatives exist separately from it, and it is possible to substitute it with other hosting sources. What would be sold in regards to the Registry is more appropriately labeled as a hosting service, but trying to sell that as your primary value-add feels like a dead-end when approaching silicon vendors.
The value you add to silicon vendors is more appropriately advertised as a support contract and sponsorship agreement, as we've outlined several times in the discussion above without it being directly addressed by you. In particular, the value Raspberry Pi Trading would gain by paying you has more to do with signaling affiliation to your open-source values than anything else.
The next primary source of value could be seen as sponsoring your technical support in further integrating their devices into your platform. You could help them integrate their official Raspberry Pi SDK into the PlatformIO toolchain, and provide robust support for that to your developer community. Notably, that is separate from integrating this community core with Arduino platform support and much improved debugging integration (though part of your offer could also be offering support to further develop the community core such that Raspberry Pi can advertise it as an official tool)!
As you can see from that value-chain, taking away from your open-source, for-the-community, developers-first narrative actually robs you of a bargaining position. The matter of what you're offering and how you're presenting it is now of public concern, given the effects it has had on your treatment of the developer community you depend on in order to have any leverage in talks with silicon vendors.
The problem with your argument over the potential precedent set here is that this PR is obviously not a thinly-disguised effort by Raspberry Pi Trading to get more robust support for their core incorporated into your Registry. The public dialogue in this thread makes that clear. This PR was prepared and ready to merge, after much discussion with your team implying that it would be, by Aug 2022. Eben Upton has made it clear that you first approached Raspberry Pi Trading in Oct 2022. You were not even on their radar before then.
Moreover, this timeline, and the fact that from Aug 2022 to April 2023 your team was completely silent on this PR despite repeated popular attempts to get further traction and input on it from multiple community members, suggests a rather opposite narrative: that you're setting a precedent of ignoring the will of the community and prioritizing (you see as) your own self-interests over what would be best for the developer community.
Summary:

Merging this PR would certainly not set a precedent which would allow future updates to vendor platforms which bypass your ability to seek support contracts from vendors.
Let's be more clear about what you're trying to sell to silicon vendors, so that we can help you better present your value-add to them.
You've dodged addressing how you completely ghosted the developer community for over half a year while holding this PR hostage as you tried to negotiate with Raspberry Pi Trading. This behavior may have directly impacted your ability to close a deal or receive further engagement with them. We need to receive affirmation that you will seek more proactive engagement and honest communications going forward.

"Sour grapes" reactionary de-listing of Raspberry Pi could be contagious
As my most recent post stated, your recent comment would seem to suggest that you're now planning to reactionarily de-list Raspberry Pi products from your registry entirely:

We appreciate your suggestion to inform developers that the integration may not be recommended for commercial use. We will discuss this internally and find a way to gracefully remove support for Raspberry Pi Trading products without disrupting existing users. In the meantime, we advise users to consider migrating their projects to the tools recommended by Raspberry Pi Trading themselves.

Should we be concerned that you will do the same for, e.g., Atmel and STMicro in the future if they refuse to negotiate on support contracts too?

To better illustrate my point, here's some brochure copy I've drafted to highlight what I see as your value add. This would be targeted at presenting to silicon vendors:

Front Cover
Empower Your Developers with PlatformIO: The Premier Embedded IDE for All
Inside Left Panel
Welcome to the Future of Embedded Development
PlatformIO, the world-renowned embedded Integrated Development Environment (IDE), offers a unique opportunity for silicon vendors like you to collaborate, innovate, and create. Designed with an unwavering commitment to community engagement and developer support, PlatformIO champions vendor-agnostic approaches to ensure universal compatibility and unparalleled ease of use.
Inside Center Panel
Powerful Benefits for Silicon Vendors
PlatformIO's value lies not only in its robust technical features but also in its ethos and commitment to an open-source community of over three million developers. By partnering with us, you signal your dedication to these values, enhancing your company's image and strengthening your connection with developers worldwide.
Integration and Technical Support:
We offer dedicated support for integrating your silicon into the PlatformIO IDE toolchain. Whether it's the Raspberry Pi SDK for the RP2040 microcontroller or Atmel and STMicro's latest offerings, we're ready to assist, ensuring seamless integration and maximum performance.
Community Engagement:
Becoming part of the PlatformIO ecosystem means direct access to a vibrant community of developers. From comprehensive documentation to lively forums, we facilitate robust dialogue and knowledge sharing, providing an invaluable resource for your users.
Inside Right Panel
Driven by Values, Committed to Excellence
Originating from Kyiv, our small yet passionate team is a testament to resilience and dedication. For over eight years, we've been nurturing the best vendor-agnostic IDE in the embedded world, providing an entirely free and open platform for developers. Our mission is to ensure each silicon vendor gets their due spotlight while fostering a collaborative and inclusive developer environment.
Back Cover
Join the PlatformIO Family
Let's align our values, integrate our technologies, and ignite a shared passion for innovation. Join PlatformIO today and contribute to the future of embedded development.

Here are some further ideas for ways you can add value to silicon vendors by leveraging your platform in ways that don't compromise the developer experience:
1. Developer Events & Webinars:
Organize events and webinars that highlight the capabilities of the vendors' products in conjunction with PlatformIO's IDE. Show how easy it is to develop with their silicon using your IDE, provide hands-on tutorials, and create an open forum for Q&A. Vendors would appreciate this exposure and the opportunity to engage directly with the developer community.
2. Co-Branded Marketing Efforts:
Offer to participate in co-branded marketing efforts. This could involve anything from social media campaigns to joint press releases. This shows vendors that you're not just integrating their products into your toolchain, but also actively promoting them to your community.
3. Highlight Vendor-Specific Features:
Work closely with vendors to identify unique features or capabilities of their silicon and then highlight these features within PlatformIO. This could take the form of special tutorials, documentation, or tooling tailored to those features, making it easy for developers to get the most out of that vendor's products.
4. Advocate for Vendor Products:
Actively advocate for the vendor products by creating case studies or success stories of projects built with their silicon using PlatformIO.
5. Product Roadmap Collaboration:
Invite vendors to collaborate on PlatformIO's product roadmap. This can help vendors see how their products fit into your long-term plans and demonstrates that you're committed to a true partnership.
6. Vendor Spotlight:
Create a "Vendor Spotlight" series in your newsletters, blogs, or podcasts, where you highlight a different vendor each time, talk about their products, and how they integrate with your IDE. This can boost the vendor's visibility among your user base and show that you're committed to supporting them.
7. Early Access Programs:
Provide vendors with early access to new features and updates. This allows them to ensure their products work seamlessly with your latest releases and gives them an advantage over their competitors.
8. Exclusive Beta Programs:
Engage vendors in exclusive beta programs where they can leverage and validate their technology with new or cutting-edge features from PlatformIO before general availability. This can provide them with a marketing edge.
These are just a few ideas I've brainstormed today that can help you sell partnership deals. I'm sure there's other ways you can pitch partnerships that don't degrade the core platform by creating a sense that you must aggressively gate-keep the Registry from the community.

I apologize for any confusion. We typically don't charge hardware vendors directly for using PlatformIO. Instead, hardware vendors benefit from the collaboration we establish with the silicon providers whose products they use. An example of this collaboration is the partnership between Adafruit and Espressif, where Adafruit sells ESP32-based boards leveraging the work we've done together.

So only hardware vendors that have their own silicon design are charged? This is a bit confusing as silicon vendors are often also hardware vendors to various degrees. There's also cases such as multiple silicon vendors licensing the same design where it's unclear who would be charged.

The pricing structure for silicon vendors depends on various factors, including the complexity of integration and the specific requirements of the solution. We outline these details in a comprehensive business proposal tailored to each vendor's unique situation.

So this integration should have negligible costs since it is effectively already complete? Am I understanding that correctly?

Thank you for your perception, and I take it as a compliment.

I think @Bondrake was pointing out that your answers are a bit evasive like lawyers often are. Maybe it's just language barrier but it's still far from clear what the situation is exactly based on your responses as they often fail to address the questions.

The choice of how you build your business is ultimately up to you. At PlatformIO Labs, our business strategy incorporates a combination of different models.

Yeah, open source projects often have different models, often running various activities under a non-profit entity. For example I contribute a lot to buildroot which has a non-profit association with sponsors as well as commercial support providers. We don't make merging contributions conditional on vendor payments the same as most open source projects. We also maintain support for a number of raspberry pi boards.

An analogy that comes to mind is the Apple/Google store approach. Companies that sell their apps through these platforms pay fees to leverage the technology provided.

Companies selling apps/services through the Apple/Google store often directly charge the customers the app store fees, for example twitter does this.

On the other hand, Apple and Google offer free access to their operating systems, not charging end users of mobile phones. This revenue funnel through the store helps compensate for the expenses involved.

Android is an open source project based on the Linux kernel but Google does charge phone vendors licensing fees for access to their proprietary userspace applications. With Android at least a huge issue is that vendors usually don't upstream their kernel drivers properly, even though the Linux kernel does accept vendor contributions without fees. The lack of vendor participation impacts security/usability of Android a lot and fee based gatekeeping policies would only move things in the wrong direction by discouraging vendor participation in upstream projects. I don't think it's a good idea to scare away vendors from contributing to projects by requiring payments to be allowed to make upstream contributions in general.

We did not anticipate that Raspberry Pi Trading would ignore us, so we approved multiple commercial Raspberry Pi Trading packages that this PR depended on while awaiting their response.

I'm not sure why you would expect an entity like Raspberry Pi Trading to respond at all when asked to pay for having a community developed pull request merged unless you had a prior business relationship with them.

Recently, we received an official rejection of our business proposal from them.

In my experience getting vendor engagement is often difficult even when doing so would benefit the vendor and cost them effectively nothing(for example releasing existing driver reference source code/documentation for say porting a driver to Linux). I've often had to reverse engineer vendor interfaces to write drivers when vendors are uncooperative. Even getting vendors to release source code they are legally obligated to provide(say due to a GPL license) can be difficult in my experience.

As a result, we informed the community that we don't plan to pay for Raspberry Pi Trading bills to maintain their commercial products within our ecosystem.

Expecting silicon vendors to pay for having community contributions for projects they aren't involved in merged upstream doesn't seem likely to work in most cases based on my experience.
Additionally characterizing their refusal to pay "license" fees in order to have a community developed pull request merged as them not paying their "bills" is not accurate, you can't just go claiming an organization in which you have zero business relationship with isn't paying their "bills" unless they had explicitly agreed to those "bills" in the first place.
Claiming they aren't paying their "bills" when they never agreed to any bills in the first place could be construed as slander. I certainly wouldn't want to work with a company that openly attacks my reputation like that. Hopefully this is just a language barrier issue.

In summary, I recommend that users in this thread and anyone interested in official support for Raspberry Pi Trading products (MCUs, Arduino framework, and Pico SDK) collectively express their interest and directly contact Raspberry Pi Trading.

I don't think it would be fair to have users ask them to pay license fees without actually knowing what the fees are. Especially since they would likely have to pass those costs on to their customers by raising prices on their products.

I read the entire thread and I think it's important to note that the community in general has three different problems:

Lack of clarity on why this specific PR has not been accepted, despite being well written and clearly strongly committed to, while initially making vague claims calling into question the quality of the PR (which turned out to be fake reasons). Leading Earl along for over a year requesting changes while secretly being blocked internally for hidden reasons (the secret negotiations with whatever RPi business unit).
No way forward for this strongly desired PR to be merged. @ivankravets wants to be able to financially support this integration. @earlephilhower has contributed presumably hundreds or thousands of hours of free work to get this ready. The Raspberry Pi organization has declined the secret licensing agreement to pay Platformio.

So... solutions.

The truth eventually came out, but I would hope that in the future if a similar PR is blocked the fine folks at PlatformIO could respect the community contributors enough to tell them what's going on. Even "We're in the middle of some business negotiations and can't merge this PR until they're done" would have gone a long way to keep people in the loop once the PR was stalled for a few weeks. It would be nice if Platformio could apologize at least informally to Earl for casting unfounded aspersions on his code quality as a delay tactic.
The ball is entirely in PlatformIO's court. It's frustrating for the community to think "we want this feature so much a member of the community has gone and implemented it on your behalf, and yet you're blocking it because an unrelated third party has declined to pay for the feature to be supported". Which unrelated party? Raspberry Pi Trading Ltd. They've got nothing to do with Earl's contribution, financially. They didn't ask for it, they don't need it. It's just an open source platformio contribution and should be judged solely on its own merits. If it costs money to support this specific PR, please provide some means forward for the people that want it to pay for that support.

Finally, it would be really helpful to future contributors to make it very clear which platforms you're willing to accept contributions for, and which you are not. That's still very unclear right now. Once you've done that, it would be nice to have documentation explaining how the community can go about adding support for new platforms.
That's the baffling part for most people here. The open source community is trying to work with platformio pretty darn hard. It's a wonderful tool. And yet... you're trying to involve unwilling third parties under the table. I can't pick your business model for you, but I'm a bit skeptical that this one is going to work out.
How can the community move this forward, without Raspberry Pi Trading Ltd.? That's all we're hoping for. We didn't even know they were involved in this PR, and for that matter neither did they :/

If you are stalling this PR for ransom money that Raspberry Pi Trading doesn't want pay, then how much money is it? Can you at least put up a Gofundme or something so that the community can directly pay you to make this a functional open source project again?

Also, can you get me some additional pricing?

How much money is needed to fast-track a PR through the review process, bump it up in priority and maybe skip a few steps?
What's the price if I want PIO to remove support for a competitor's products or stall another PR secretly?
Do you have rates for banner ads within the PIO home screen?

PlatformIO's current business model is business-facing now, correct? I presume that when PlatformIO negotiates fees with hardware manufacturers to be included in this open-source project, the proposed value-add looks something like this:

Onboarding and modernizing their technology stack to the nimble, community-supported open-source experience today's developers expect
Interfacing productively with community contributors to facilitate steady improvement of platform support
Testing upgrades and responding quickly to issues reported by the developer community
Acting as a community liaison to facilitate effective communication and participation at the ground level, where traditional business often struggle to maintain velocity

How many of these value-add features are effectively demonstrated to potential PlatformIO business partners by the discussion above? And if my list is completely wrong, what advantages are proposed to business partners instead?

"hardware manufacturers to be included in this open-source project"
When you refer to "this open-source project," I assume you are referring to PlatformIO. It's important to note that PlatformIO Core and its related repositories, including IDE integrations, are designed to be agnostic to specific hardware manufacturers and vendors. Our business strategy is centered around openness, allowing partners to collaborate on the project if they choose to do so.
If you are referring to a development platform or integration component that connects vendors' products to the PlatformIO ecosystem, it can be either open or closed-source depending on the vendor's policy. The commercial components are housed in the PlatformIO Registry, and our technology partners personally manage the distribution of their packages to ensure their customers have access to up-to-date and bug-free software.
"what advantages are proposed to business partners instead?"
Rather than focusing on promoting PlatformIO here, I would appreciate hearing your perspective on why you prefer PlatformIO over the official tools provided by silicon vendors. As the C-level individuals from Raspberry Pi Trading are participating in this thread, your insights would be valuable to them.
As mentioned in my previous comment, if this PR were to be merged, PlatformIO Labs would be compelled to compete directly with Raspberry Pi Trading, as they have decided to steer their customers towards a separate installer for Windows instead of utilizing PlatformIO. However, we are not interested in engaging in this challenge or succumbing to provocation. Consequently, there will be no further updates to this repository (integration).
Our mission is to offer complementary solutions to our business partners rather than competing against them. There are other silicon vendors who understand how to leverage PlatformIO Labs Technology, redirecting funds that would have been spent on "tools that developers dislike" towards enhancing their own product development and overall improvement. This approach aligns with our vision of fostering a positive and cooperative environment.

Why I preferred PlatformIO was due to two main reasons:

The perception of a healthy community of developers, ensuring rapid discovery of bugs and quickly supporting new hardware
Insulation from slow, buggy vendor solutions and more importantly the typical levels of corporate red tape and BS

Both points have been significantly damaged in the past week, unfortunately.

This approach aligns with our vision of fostering a positive and cooperative environment.

In what way does holding a significant PR hostage while you shake down an external company for payment for something they didn't order 'positive and cooperative' ?
If I was part of Raspberry Pi Trading, I'd have turned down the demand as well - this is no way to build business relationships or trust in your platform.

@dhennessy Unfortunately the reason is obvious, and our grumbling over this PR serves the business interests of PlatformIO.
The main product that PlatformIO has to sell to other companies is a large group of potential customers for hardware products: us.
You can see that that Ian continually glosses over our concerns about PlatformIO’s behavior but pounces upon and amplifies anything that could be construed as a complaint about Raspberry Pi’s existing development solution. One could claim that Ian is vigorously trying to sell the work of @earlephilhower and @maxgerhardt to Raspberry Pi. Our participation in this thread increases the value.
It’s a valid and quite shrewd business tactic, but jarring in contrast with typical open source communities.

Ian is vigorously trying to sell the work of @earlephilhower and @maxgerhardt to Raspberry Pi.

Wow! It appears that I now understand why some people in the comments may have the perception that we are selling Max's and Earle's work or pressuring Raspberry Pi Trading into adopting our solutions.
This repository serves as a demonstration of the value proposition between PlatformIO and Raspberry Pi products. Almost a year ago, we reached out to Raspberry Pi Trading with a comprehensive business proposal that outlined integration, ongoing maintenance services, and professional support for Raspberry Pi Pico SDK and Arduino-based frameworks. We are also open to discussing the integration of other frameworks like Zephyr RTOS and Nuttx if there is demand from the community.
At PlatformIO Labs, we typically provide initial integrations written from scratch by our engineers to ensure seamless alignment with the ecosystem's APIs, thereby offering one of the best developer experiences. We genuinely appreciate Max's and Earle's contributions to this PR, and we are committed to reviewing similar PRs submitted to the repositories of our technology partners.

ddress this issue by making Raspberry Pi Trading aware of your dissatisfaction

this is so ridiciulous... no, I won't

PlatformIO Labs would be compelled to compete directly with Raspberry Pi Trading, as they have decided to steer their customers towards a separate installer for Windows instead of utilizing PlatformIO

In my/our (OpenKNX) case it was never the choice between using RPi Toolchain (alone) or PIO. We began using it with VSC, Microsoft Arduino Plugin, Arduino and, Earles Core.
PIO had some nice features, so we switched.
For living, I lead a embedded-SW-dev team for a Fortune 50 company. We use Greenhills, and for sure, we pay for it. Why not? There is nothing bad in paying for a good product.
I never would consider using PIO anymore, not with that business model and that business conduct..

Wow! It appears that I now understand why some people in the comments may have the perception that we are selling Max's and Earle's work or pressuring Raspberry Pi Trading into adopting our solutions.

What did you understand? You said you understood why, but then said a bunch of other stuff that didn’t explain anything. I am curious about your epiphany.

@Ing-Dom, I appreciate your perspective on paying for a good product and understand your concerns about PlatformIO Labs' business model and conduct. It's important to note that PlatformIO Labs aims to provide a balance between free and professional tools for the embedded development community.
Let's consider a scenario where Greenhills does not offer support for Raspberry Pi products. In such a case, what reasons would you provide to justify paying for their solutions instead of utilizing PlatformIO?
I'm curious to know if you personally pay for Greenhills solutions or if it's your company that covers the expenses. Understanding this distinction can provide further insights into your perspective on the value of paid solutions versus free ecosystems.
Thank you for sharing your thoughts, and I'm interested in hearing more about your experiences and reasons behind your choices in the embedded software development field.

Wow! It appears that I now understand why some people in the comments may have the perception that we are selling Max's and Earle's work or pressuring Raspberry Pi Trading into adopting our solutions.
This repository serves as a demonstration of the value proposition between PlatformIO and Raspberry Pi products. Almost a year ago, we reached out to Raspberry Pi Trading with a comprehensive business proposal that outlined integration, ongoing maintenance services, and professional support for Raspberry Pi Pico SDK and Arduino-based frameworks. We are also open to discussing the integration of other frameworks like Zephyr RTOS and Nuttx if there is demand from the community.
At PlatformIO Labs, we typically provide initial integrations written from scratch by our engineers to ensure seamless alignment with the ecosystem's APIs, thereby offering one of the best developer experiences. We genuinely appreciate Max's and Earle's contributions to this PR, and we are committed to reviewing similar PRs submitted to the repositories of our technology partners.

If this PR isn't what you were trying to sell, then it makes even less sense to me that you are refusing to merge it unless Raspberry Pi pay you.

Let's consider a scenario where Greenhills does not offer support for Raspberry Pi products. In such a case, what reasons would you provide to justify paying for their solutions instead of utilizing PlatformIO?
I'm curious to know if you personally pay for Greenhills solutions or if it's your company that covers the expenses. Understanding this distinction can provide further insights into your perspective on the value of paid solutions versus free ecosystems.
Thank you for sharing your thoughts, and I'm interested in hearing more about your experiences and reasons behind your choices in the embedded software development field.

You have to divide between my OSS project OpenKNX, where we use RP2040 (and, previously, SAMD21).
We always used Arduino as framework and we are dependent on free or almost free solutions.
Paying would never be an alternative. We are struggling now with our slack channel due to the limitations.. thinking about applying for slack for nonprofits.
And as open source enthusiats, clearly prefer free as in freedom rather like in beer.
In my opinion, to keep open source projects alive you are dependent for new people to join - and for that very low entry barriers are curcuial.
In my professional role, we do not use the RP2040 but a bunch of STM32 microcontrollers. I doubt they support RP2040.
Main reason is the IEC 61508 certification - and historical reasons.
And, yes, the company pays for the license / support contract we have.
Licence cost do not really matter, they are so small compared to personnel cost - lets say a tool save one hour per month per developer... with that 1500Euro you can even pay for a MSDN with VS pro subscription (which is not an option for embedded developement).

@Ing-Dom, thanks for the valuable information. Let me share some historical things.
We have been active in the embedded systems market since 2014 and have gained valuable insights over the past nine years. I encourage you to read my post on LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:7070359816442978305/) where I explain our decision to break away from the rules established by certain monopolistic entities several decades ago.
Prior to 2019, we attempted to adhere to these rules and added nearly 40 development platforms (integrations with PlatformIO) during that period. We invested significant resources and were surprised by the results. We expected silicon vendors to appreciate our mission and join our revolution. It's worth noting that we did not charge these silicon vendors at the time. However, the more popular PlatformIO became, the more animosity we encountered from engineers working on their proprietary IDEs within these companies. Later, influential individuals from some semiconductor companies shared intriguing information with me. It was the first time I learned about the concept of "vendor lock-in". Consequently, it became clear that "vendor lock-in" is a key strategic approach employed by marketers in the silicon industry. As you now understand, PlatformIO stands in direct opposition to this strategy. The more obstacles silicon vendors create for their customers, the higher the likelihood that customers will remain loyal to their products, even in the presence of cheaper and superior alternative solutions.
The second challenge we faced was the lack of technical support from the silicon vendors whose products we supported at that time. Whenever we encountered issues, primarily related to integration or desired improvements such as debugging capabilities, we rarely received satisfactory responses. The typical answer was, "We only provide support for our tools, which are the only ones recommended for our customers". As a result, our integrations were limited, and providing professional support became a challenge.
Consequently, despite our substantial investments in the silicon industry during that period, we faced backlash from major players because their engineers and marketers were uncertain about how to handle our growing popularity and the reasons why their customers preferred PlatformIO over their tools, for which they had invested millions.
In 2020, we made the decision to exit this room dominated by an oligopoly and no longer adhere to their "lock-in" rules. We conducted an experiment: rather than seeking to support all MCUs and related software, let's focus on having 2-3 official platforms (integrations) with excellent support from the vendors. The results were astonishing. We witnessed a significant increase in the number of PlatformIO users utilizing our platform for commercial projects, which is our primary goal in dismantling this oligopoly. We were astonished by how rapidly our user base grew. You can verify the public statistics for just one of our IDE extensions (https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide) and read the reviews.
What we learned is that there's no need to support everything. We don't have to abide by rules that leave developers dissatisfied and hinder our mission. If you want to effect change and become the industry leader, you must ignore the criticisms from major players whose primary focus is their own business interests.
Regarding the statistics, by competing against players pursuing a "lock-in" strategy, we managed to add support for 40+ development platforms and build a community of 500,000 users between 2016 and 2019. Conversely, by disregarding the haters and prioritizing partnerships with those who appreciate our ecosystem, we built a sustainable business and grew our user base to 4 million since 2020. Now, you can calculate who has emerged victorious in this battle. It's not just PlatformIO Labs or our detractors, but our partners who have increased their brand visibility and instilled confidence in their customers by offering true freedom of choice.

Okay, so if I oversimplify a bit what Ivan has been saying:
This sounds like PlatformIO wants to switch to focusing on supporting just platforms where they have a direct vendor contract.
My suggestion then would be to find a way to move all of the "community" platforms out of the hosted registry, get the community to actually host them, and put up a big disclaimer that the PlatformIO team doesn't manage them.
Otherwise it sounds like the project is at an impasse where the community is almost unanimously at odds with the founding team over priorities.

It sounds like there's a few platforms like STMicro and Atmel which the PlatformIO team feels obligated to maintain some official support for, so I would suggest adding a new category for these "legacy supported" platforms in the registry with some more explicit guidance on the level of maintenance there as well.

I think this is a very suitable proposal.
I have used PlatformIO for serious academic projects, using platform-atmelsam, and our group has donated to support PlatformIO, which was an amazing solution. It is very import for that quality to be maintained. In order for that to happen, the PIO Labs team cannot be spread too thin, and needs to be financially solvent to continue to exist.
I've also used PlatformIO for various side projects, including with my RPi Pico. I am not upset knowing that RPi is not an officially supported vendor, and I'll continue to use it in a "community" supported fashion. If I were starting a "professional" project, I would not select RPi on PlatformIO, but that's okay.
I think it's important for the PIO Labs team to make this division more clear, and provide an easy interface for users to use community platforms, with the understanding that they cannot provide the same level of support.
It's not reasonable to expect that PIO will support all platforms, and it's not reasonable to expect that all vendors will support their products on PIO. I would hope that with a community support package, the size of the community would grow, until one of two things would happen:

RPi would see the popularity and wish to be included as a supported vendor, and work with PIO Labs to make that happen
PIO Labs would get lots of feedback from potential paying customers that they wish to use that platform, and decide to go after that market by providing the supported platform.

Or, this does not happen, and it stays as a community platform.
With regards to how this PR is handled, I think it's important for the PIO Labs team to understand that to many people, "Open Source" means more than just the source license, It's also the ethos of the community. Even when a project is managed by a company, we feel there is an implicit agreement that decisions about the code should be made to improve the project, for the community and not just the company. You need to explain why the decision you're making isn't user-hostile, but is actually just one decision within a larger plan that allows you to keep making revenue and keeps the project alive.
If a future PR comes along like this one, the response should be "We cannot do this, please see this explanation, but you are free to host this unsupported platform yourself and here is the interface to tie it into PIO". I think most people will be accepting of that approach.

PLEASE READ BEFORE =>  📅 Discussion Timeline  📅

"I have used PlatformIO for serious academic projects, using platform-atmelsam, and our group has donated to support PlatformIO, which was an amazing solution. It is very important for that quality to be maintained. In order for that to happen, the PIO Labs team cannot be spread too thin and needs to be financially solvent to continue to exist."

Thank you, Tim, for sharing your positive experience with PlatformIO and supporting our project through donations. We truly appreciate it, and maintaining the quality of our services is indeed crucial for us. We understand the importance of having a dedicated and financially stable PlatformIO Labs team to ensure ongoing development and support.

"but is actually just one decision within a larger plan that allows you to keep making revenue and keeps the project alive"

Indeed, this decision is part of a larger plan aimed at sustaining PlatformIO and generating revenue to ensure the project's continuity. As I mentioned before, our licensing model is not a new concept. The PlatformIO Registry Policy clearly states that silicon vendors seeking to leverage the PlatformIO ecosystem and provide commercial integrations (packages) must obtain a technology license from PlatformIO Labs.
We are committed to protecting our business and will not tolerate attempts to evade licensing fees. We have various measures in place to safeguard our interests.

"I think it's important for the PIO Labs team to make this division more clear and provide an easy interface for users to use community platforms."

We have taken steps to address this concern and provide clarity. The current PR is an example of how we enable the use of community platforms within our ecosystem. We have gone a step further by approving multiple commercial packages to support this PR. Our intention was to facilitate a positive user experience.
However, we underestimated the possibility of individuals trying to circumvent our licensing policies, which is unfortunate. We didn't anticipate that in the 21st century, people would still attempt to "crack" or exploit software. Personally, I believe that if I appreciate a software product, I should pay for it. If I don't want to pay, I simply choose not to use it. I respect the efforts that companies invest in their products.
Regarding protecting our business in this scenario, we are actively exploring different strategies. It's a complex issue, but we remain committed to finding solutions to safeguard the interests of our ecosystem and the PlatformIO community. We appreciate any suggestions or ideas you may have on this matter.

"RPi would see the popularity and wish to be included as a supported vendor and work with PIO Labs to make that happen."

We cannot predict whether Raspberry Pi Trading will choose to collaborate with us or seek to be included as a supported vendor. As outlined in the Discussion Timeline, we have not pursued aggressive sales tactics or spamming potential customers. We were content for over 20 months without any response from Raspberry Pi Trading. Our decision to contact them again was driven by the negative sentiment expressed by our community regarding this issue. Our hope was to resolve this matter without excessive drama and an influx of comments.
At this point, we do not plan to reach out to Raspberry Pi Trading again. If they perceive business value in the PlatformIO ecosystem, they know how to reach us, and we would be more than happy to restart our dialogue. Alternatively, as their customers who utilize their MCUs, you have the option to reach out to them directly and express your interest in using PlatformIO for programming their products. Your feedback as customers can potentially influence their decisions.

Summary of the above pseudo-lawyerism: We were happy to ignore a rapidly growing platform for 20 months, during the time it was possibly the only chip our users could source. Also, we’ve now equated community contributions to an open source project with cracking a license.
I’m not sure where this visibly increasing paranoia is coming from, but it is going to drive away both users and customers. I suggest hiring someone else to handle front facing communications.

Indeed, this decision is part of a larger plan aimed at sustaining PlatformIO and generating revenue to ensure the project's continuity. As I mentioned before, our licensing model is not a new concept. The PlatformIO Registry Policy clearly states that silicon vendors seeking to leverage the PlatformIO ecosystem and provide commercial integrations (packages) must obtain a technology license from PlatformIO Labs.

This is far from clear to me.
The silicone vendor is not seeking anything, this PR is not produced by them. Quite the opposite in fact - They have demonstrated that they don't really care, at least for the price you're asking.
Raspberry Pi Trading are neither seeing to leverage the PlatformIO ecosystem (As above, they don't care) and they are not providing a commercial integration. (This is an independent contribution by a third party)
On the issue of piracy and bypassing licensing I refer you to some wisdom from Gabe Newell, the co-founder of Valve Software:

The easiest way to stop piracy is not by putting antipiracy technology to work. It’s by giving those people a service that’s better than what they’re receiving from the pirates.

In other words, don't try to fight it - Just offer value. Trying to block specific silicone goes against this.

I volunteer with the team that created the non-profit FOSS physical computing tool MicroBlocks. It's the only blocks-based IDE for physical computing (targeting younger students) that is truly live, like Scratch. I've taught many a workshop and kids with no coding experience pick it up easily. Our growing community will only buy boards that MicroBlocks supports, myself included.
MicroBlocks depends on PlatformIO to build the Virtual Machine (VM) images that make the "live" magic happen. First step with a new board is to install the MicroBlocks VM. This step is usually done by teachers/trainers who buy the boards -- it is an easy one-click process from the IDE. Thereafter, coding is "live". Currently we have VM support for several different microcontrollers, including the RP2040. (There are 40+ board envs in our platformio.ini file). Without support for RP2040 in PlatformIO to build the VM, we may have to drop the RPi Pico and any board or kit that use this great new microcontroller chip (such as Pico:ed, PicoBricks, Xiao2040, etc.)
The next generation of physical computing innovators would greatly benefit from official MicroBlocks and official PIO support of RP2040. It seems a shame for Raspberry Pi Trading to ignore the STEM education market that we support with the free MicroBlocks IDE. I would like to see RPi Trading try a bit harder to negotiate a means to do win-win business, financially and development wise, with PIOLabs. I do not know the barriers to a win-win deal, but I would be happy to be a mediator in a call between @ebenupton and @ivankravets to help resolve this issue. It's in the best interest of students everywhere, and the rest of us will cheer in relief too.
( /me crosses fingers)

Am I the only one that finds it quite disturbing that a non-profit organization as Raspberry Pi (yes, it's the Trading Ltd, but they are owned by and their profits go to the Foundation) should pay license fee?
I don't think so. That is not the way non-profit / open source entities work together.
Maybe the reason is simply, that Plattform I/O is not (anymore?) so open as it seems to be.
That is ok, we all need to earn our money. Thats what companies are for.
But this does not go together with the "look and feel" of Plattform I/O to be an open source project, and asking for donations...
https://platformio.org/donate
No, that is not honest.

Keep PlatformIO Project NEUTRAL for any architecture, hardware, or software products

Where is the neutrality, if only paying silicon vendors are supported? Right. Vanished..
I know that is difficult to be free (as in freedom) and also earn money, our just "handling" substanital parts of money without profit and keep the open source spirit...
But how Plattform I/O handles this atm, feels quite dishonest to me.

I'd like to say first that I have really enjoyed using PlatformIO CLion integration for the past few years, and thanks for that. Many here probably donate to platformIO as I do myself and at least a brief mention of the end state would be nice. At the moment, I'm assuming at some point in the next few weeks RPi Pico development will stop working entirely in platformIO from the comments above.
My question is: Should the decision be taken to delist all Raspberry PI packages (as has been discussed further up), would we be able to source enough components from GitHub to make Raspberry PI development and debugging possible (at least for community / non-commercial use)? Or put another way, would the current way of working continue to be viable?

The question is... This is an OpenSource project with community efforts??? So if is built on community efforts, then must listen to the community. I don't found the point of not accepting a PR only because is about a project that will not send license feeds?? Really???

Certainly, I understand the perspective you're raising. It's important to clarify a few aspects of the situation.
PlatformIO is indeed an open-source project, and we greatly value community contributions. However, it's essential to recognize that PlatformIO is developed and maintained by PlatformIO Labs, a commercial company. Our team invests significant time, effort, and resources into creating and improving the PlatformIO ecosystem.
The core tools for embedded software development, such as the PlatformIO IDE and PlatformIO Core, are open source and provided for free to developers. Our business model involves partnering with silicon vendors to enable them to utilize our advanced technology and ecosystem for their products. This helps reduce their software development costs and offers their customers a robust development environment.
When it comes to PRs like this one, it's not simply about accepting or rejecting based on license fees. It's about maintaining a sustainable ecosystem for both the community and our company. We are more than willing to collaborate with silicon vendors, but we do ask for a fair arrangement to sustain our project. This approach ensures that we can continue to provide high-quality tools and support to the community.
It's not a matter of refusing contributions; rather, it's about aligning business models in a way that benefits everyone involved. Open source does not imply working without financial sustainability; it's about finding a balance that fosters growth and innovation while providing value to all parties.
I hope this clarifies our position and approach. We are always open to discussions and collaboration that respect the interests of both our community and our commercial endeavors.

The question is... This is an OpenSource project with community efforts??? So if is built on community efforts, then must listen to the community. I don't found the point of not accepting a PR only because is about a project that will not send license feeds?? Really???

Yeah the project advertising contradicts actual policy. I've suggested that @ivankravets correct this but there doesn't seem to be an interest.

It's not a matter of refusing contributions; rather, it's about aligning business models in a way that benefits everyone involved. Open source does not imply working without financial sustainability; it's about finding a balance that fosters growth and innovation while providing value to all parties.

I think the reason everyone is so confused here is due to the project still being inaccurately advertised as "A place where Developers and Teams have true Freedom(Use favorite OS, IDE, Hardware and Software tools)! No more vendor lock-in!".

We are always open to discussions and collaboration that respect the interests of both our community and our commercial endeavors.

I've not seen any attempts to come to a community arrangement that doesn't involve the hardware vendor's participation(which is something they have already indicated they are not interested in). You don't seem willing to discuss options with anyone that is not the vendor. It's pretty silly to advertise a project as having no vendor lock-in when you require vendor participation.

by PlatformIO Labs, a commercial company.

Commercial Companies don't beg for donations!
https://ibb.co/gDZLQq7

Commercial Companies don't beg for donations, claiming they are an OpenSource-Project...

To be fair lots of open source projects are run by commercial companies, so that part isn't really inaccurate. Running donations through a commercial entity is a bit unusual but it's not really false advertising like the no vendor lock-in part.

I think the reason everyone is so confused here is due to the project still being inaccurately advertised as "A place where Developers and Teams have true Freedom(Use favorite OS, IDE, Hardware and Software tools)! No more vendor lock-in!".

You're absolutely right in pointing out the discrepancy, and we appreciate your feedback. The issue of vendor lock-in is a significant concern in the semiconductor industry, where customers often find themselves tied to a specific vendor's tools and products, limiting their options. Our mission is to break down those barriers and provide developers and teams with the freedom to choose their preferred tools and hardware without being constrained by a single vendor.
We've taken your feedback to heart, and as a response, we've revised our website and documentation to better reflect the power and benefits of the PlatformIO ecosystem. You can check out the updated content on our website at https://platformio.org/ .

Commercial Companies don't beg for donations, claiming they are an OpenSource-Project...

You're absolutely right that there's a distinction between companies and individuals when it comes to donations. Our approach is rooted in providing value to both individual developers and commercial companies. We don't solicit donations, nor do we position ourselves as solely reliant on them. Instead, our primary focus is on delivering a robust and feature-rich ecosystem that enhances developers' productivity and creativity.
For many businesses, using PlatformIO results in substantial savings on commercial IDE licenses, and some express their appreciation by choosing to donate as a gesture of gratitude. However, our commitment remains in offering an accessible and free platform for end developers and companies, even for commercial use. It's worth noting that other commercial entities, like Arduino, also have the option for donations while providing a range of paid products and services.

A lot of companies have encountered the challenge of balancing open-source contributions with the need for sustainability. While open-source products are created with the intention of improving the global community, unfortunately, there are instances where some exploit them for personal gain without giving back. We appreciate the evolving landscape and the strategies companies employ to safeguard their business and community.
If you have a few minutes, I would recommend reading yesterday's announcement from HashiCorp (https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license). It illustrates a similar situation, and like HashiCorp, we are also focused on preserving our business model while keeping tools for end developers free and open source.
Thank you for your understanding and for sharing your insights on this matter.

I do want to say how much I appreciate Platform IO for supporting (almost) all of the MCU's I own, and how much I like their product. I do understand their wanting to be compensated for their work by those that benefit the most.   I guess I am not going to buy anymore RPI Pico W's, and warn all my friends about lack of support from both RPI and PIO.   (it is a lose-lose for both PIO and RPI)

Is there a community edition of platformio IDE where this change can be merged? Would love to see @maxgerhardt  hard work and contribution baked into the IDE.

Since it only takes a few simple GUI (PIO Home -> Platforms -> Advanced Install -> Git URL of forked platform -> Install) or one CLI  command (pio pkg install -g -p <git link>) steps to install the forked platform, I don't think it's necessary to create a forked PlatformIO-core or extension.

When are the requested changes expected to be approved?

When are the requested changes expected to be approved?

I would say mostly likely: never

When are the requested changes expected to be approved?

I would say mostly likely: never

😢This is really a shame. But I will keep hope.

If you have a few minutes, I would recommend reading yesterday's announcement from HashiCorp (https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license). It illustrates a similar situation, and like HashiCorp, we are also focused on preserving our business model while keeping tools for end developers free and open source.

@ivankravets It's worth mentioning for posterity that the decision by HashiCorp to switch licenses was wildly unpopular both with the community and industry partners and led to this outcome, where HashiCorp is now being forced to compete with a version of its own product that now has more backing and funding behind it than the original ever did.

Today, the Linux Foundation announced the formation of OpenTofu [...] an open and community-driven response to Terraform's recently announced license change from a Mozilla Public License v2.0 (MPLv2) to a Business Source License v1.1, providing everyone with a reliable, open source alternative under a neutral governance model.

With broad support from industry leaders like Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, Terramate, and others, OpenTofu has received formal pledges spanning 140+ organizations and 600+ individuals. OpenTofu will ensure the continued development and availability of its codebase and has a starting commitment of a minimum of 18 full-time developers over at least the next five years.

Unpopular decisions like those cause the relationship between a project and its community to deteriorate and can spell certain doom. Drawing a comparison between PlatformIO Labs and HashiCorp not only fails to address the concerns already being raised here by the community but raises entirely new ones. I hope you will clarify what you believe the similarities between the two companies situations to be.

Our business model involves partnering with silicon vendors to enable them to utilize our advanced technology and ecosystem for their products.

but we do ask for a fair arrangement to sustain our project. This approach ensures that we can continue to provide high-quality tools and support to the community.

Is it not also the case that by not permitting support for a platform, your business model is also holding back the capabilities of the technology and ecosystem you are offering?
By the very nature of being an open-source project, whether or not a vendor is "enabled" to use this technology is practically speaking beyond the control of PlatformIO Labs. This is self-evident based on the fact that a thriving community-led effort to support the Pico exists, despite a lack of cooperation from the vendor or the approval of Platform IO Labs. And as @maxgerhardt said, support for the Pico can be enabled with a few clicks.
There doesn't appear to be an upside to making an unpopular decision like this and resisting the desires of the community here. Denying the PR won't create revenue by increasing the odds of a partnership with the vendor - what would have been the net result of that partnership now exists for free. Increasing the number of platforms supported (and the quality of that support) benefits PlatformIO as a product. Given that the community created that support stemming from their own, it is likely they will also maintain it out of their own need, so the long-term maintenance cost surely wouldn't out the benefits either.
Just seems like an all around bad decision that only serves to strain the relationship with the community.

@maxgerhardt - many thanks for these developments and the fork.  I ran the command pio pkg install -g -p https://github.com/maxgerhardt/platform-raspberrypi and that seems to work fine.  Should we first (or later) uninstall the standard RP2040 board set?

Just seems like an all around bad decision that only serves to strain the relationship with the community.

Hard agree. Source-available licensing is a massive turnoff to adoption or continued support from community members.
Unlike HashiCorp, I'd imagine PlatformIO still has the ability to pivot and make decisions that are in their best interest moving forward. Otherwise, maybe close this issue and end the false hope some of us have of PlatformIO being a long-term prospect for our automation needs? :)

If the people at PlatformIO are actively preventing innovations by the community, it's time to search for an alternative. It might be time to branch off of PlatformIO and create something that's truly free and open for all creators and vendors.
Asking the Raspberry Pi Foundation for money is just scummy. All the needed code is here already.
I'm going to repeat the workaround so others looking for it can find it without having to sift through so many comments:
Open the PlatformIO terminal and execute this command:
pio pkg install -g -p https://github.com/maxgerhardt/platform-raspberrypi
You can also find more info here: https://arduino-pico.readthedocs.io/en/latest/platformio.html

We have great respect for the individuals at Raspberry Pi who have made significant contributions to the field of embedded systems. It's as if they've established a large and supportive community (comparable to a church) around their projects, where people willingly contribute. However, there are instances where individuals criticize those who choose not to contribute, and there's a reason behind this. The community is not entirely authentic, as outlined in the recent candle works ( https://newsroom.arm.com/news/raspberry-pi-investment ). While some members contribute their last coins, believing they are supporting a noble cause, the individuals behind the community are making money from them. We don't want to be part of this community, as they have even attempted to divert people from our community to theirs to avoid paying our technology fees (please read the comments above).

We, at PlatformIO Labs, have been working hard on the PlatformIO project since 2014. Our main aim is to make it easier for engineers to work on embedded systems. We want to challenge the big players in the industry and make things better for developers. Our tools are free for people to use.
To keep our business going and keep improving our technology, we charge commercial companies seeking to benefit from the PlatformIO ecosystem and reduce expenses on developing their IDE/tools. This way, we can maintain the quality of what we offer. If Raspberry Pi Trading Ltd has non-commercial products, we'd be happy to support them for free. But since their products are commercial, the usual charges apply.
Our mission is all about being open, fostering innovation, and making things accessible, especially in the world of embedded systems. We're committed to providing a great environment for developers, and we appreciate the understanding and support from our community.
P.S.: Alongside our community, we've accomplished much: starting as an outsider facing criticism for our innovative perspectives on embedded development and the introduction of declarative principles, we now establish the benchmarks that other silicon vendors are adopting. Check it out at VSCode Extension Adoption Momentum.

Just to reiterate Raspberry Pis position:

First off, I'd like to express our gratitude to Max for his amazing work. It's exciting that people have the opportunity to use a high-quality integration of PlatformIO with Raspberry Pi silicon.
We received a proposal from PlatformIO Labs in October 2022. While we absolutely empathise with the challenges of funding open-source projects, we were unable to justify paying the very substantial recurring fees involved. We indicated that we would not be proceeding, and have subsequently made some investments elsewhere, notably in the Raspberry Pi Pico Windows Installer.
As it has been made clear that this PR will not be accepted in the absence of a commercial agreement between Raspberry Pi and PlatformIO Labs, I think it would be best to close it.

I agree with Eben that you should close this PR.

@ghollingworth

we were unable to justify paying the very substantial recurring fees involved.

We attempted to initiate discussions on this matter previously, but unfortunately, we didn't receive any feedback.
If you genuinely aim to enable your customers to benefit from the PlatformIO ecosystem, kindly propose reasonable "recurring fees" that fit within your budget, and we are open to considering it. The official integration will encompass support for Pico SDK along with Arduino Cores (mbed + Earlephilhower').

@ivankravets It's not just engineers and professionals who use PlatformIO, there are a lot of hobbyists like myself that use it as well. You're preventing the community from working together by blocking this PR. If you want a walled off garden, split PlatformIO into a Community and a Professional edition.
This isn't about Rasberry Pi or money, this is about a guy that invested a lot of time to port over Arduino-Pico to work with PlatformIO. He provided everything that's needed and it already works. We're all just waiting here. Not accepting the PR because Raspberry Pi, which didn't have anything to do with this PR, isn't willing to pay a fee is madness. It's not at all in the spirit of open source and fostering an ecosystem of sharing.
I love PlatformIO, but this situation is a bad look.

This repository and integration were created by paid engineers at PlatformIO Labs as a demo project. It's important to clarify that this is not an official integration recommended for commercial use. Incorporating new and complex pull requests, such as this one, would necessitate additional financial investment to maintain these additions. As indicated by statements from representatives at Raspberry Pi Trading, they don't find value in PlatformIO, and they advise their customers to use the Windows Installer. If you have concerns or queries, it's suggested to reach out to the seller who provided you with Raspberry Pi Ltd. products.

split PlatformIO into a Community and a Professional edition.

This distinction has already been implemented - the flies are separated from the meat. This repository is a simple demo initially created to contact Raspberry Pi Trading company. PlatformIO Core and related services are not dependent on it. It's a small piece of the puzzle connecting silicon vendor products with PlatformIO.
For community options on working with Raspberry Pi products:

Refer to official Raspberry Pi Trading docs and use the Windows installer, which is the recommended method.
Download the Arduino IDE and follow the instructions at https://github.com/earlephilhower/arduino-pico#installation (highly recommended if using Earlephilhower's Arduino core).
Explore the PlatformIO community integration provided by Maximilian (https://arduino-pico.readthedocs.io/en/latest/platformio.html) if you still want to use PlatformIO. For any questions, feel free to join our active community at https://community.platformio.org/.

Hopefully, this addresses any concerns.

Hi,
I think I was the one who "accidentally" bumped this PR a few months ago.
Your last statement on the subject was the one I understood the most : "Incorporating new and complex pull requests, such as this one, would necessitate additional financial investment to maintain these additions."
I, personally as a free time developer, totally understand this. Any minor change/addition to a project like this does involve a lot of work to maintain in the long term, and adding a new device is not a minor change.
Since the very, very cool @earlephilhower repo works very fine with PlatformIo thanks to the nice interoperability possibilities of PlatformIo, I personally think this PR could be closed for now, until something new happen...
Thanks you all for your time involved here, and keep in mind we are all having fun here (well, I hope) :)

ivan still hopes to squeeze out some bucks from eben, but I think they just should have a fist fight like zuckerberg und musk to settle this finally.

Wow... just close this PR, and leave it be.
It's obvious PlatformIO does not want to work with the rest of the Pi community unless they get Raspberry Pi Trading Ltd to pay up (as if the thousands of individuals and smaller open source projects are somehow commercially interested...?). I think everyone's said their piece, and leaving the PR open just gives people false hope the community contributions will be accepted someday.

It's quite simple really... if you want a strictly 'community supported' implementation... it's there already... pio pkg install -g -p https://github.com/maxgerhardt/platform-raspberrypi and move on. If you want an officially developed and tested, ready for commercial use grade level of support... someone has to pay for development, testing, ongoing hosting fees and support (open source does not mean it's free) ... and it should be Raspberry Pi Trading since it's their product being supported. If they don't want to, that's fine. They've made their position clear - they're not interested. So yes, the PR should be closed on that note, with any and all complaints for lack of commercial grade support in the PlatformIO ecosystem be addressed/forwarded to Raspberry Pi Trading.
On a more personal note, I'm under no illusions regarding Raspberry Pi. On their own blog they stated industrial sales make up a big part of their portfolio... it was like 44% of all their sales in 2020. And in 2022 Upton was quoted as saying that they manufacture around half a million single board and compute module products each month... which were being prioritised for commercial and industrial customers. In other words, tinkerers and hobbyists are not their primary market, or even a large part of it, but more good press and advertising. There is nothing wrong with that at all... just need to keep everything correctly in perspective. ;)

We get it—the point is, this PR should be closed. There are no fruits coming out of the ongoing discussion for the past few months :)

From way back when:

Under the PlatformIO Labs licensing model, the integration and support for a specific hardware platform remain perpetual. This means that even if a silicon vendor were to stop paying recurring licensing fees or terminate the agreement, the existing integration and functionality for that platform will continue to be available to the community. In such a situation, there are no risks or negative impacts on the projects and developers who rely on that platform within the PlatformIO ecosystem.

If it's a matter of raising funds one time—what is the dollar amount that would make PlatformIO happy? I personally will donate $1,000 to Platform IO for Pico support, just to make it easier to use third-party projects which rely on it, like ESPHome, with the Pico (that gives me the freedom to use the microcontroller I want in a project). We could start up a GoFundMe or something, if you like.

Sources, please...

From the horses mouth 🤭
https://www.raspberrypi.com/news/supporting-raspberry-pis-industrial-customers/
https://www.raspberrypi.com/news/production-and-supply-chain-update/
I don't know what the current support model is - it seems like it's now only communicated B2B as there doesn't seem to be any real mention of it any more. But it would be interesting to see if PIO would consider crowdfunding to add support for the Pico... it would be good to see something more accessible than a somewhat unusual (as in, from the norm) package install command in order to use it. But I fully agree... this is just beating a dead horse atm... 🤪

If it's a matter of raising funds one time—what is the dollar amount that would make PlatformIO happy?
I suggested this like a year ago, but @ivankravets is not interested in such a funding.
RaspberryPi hast to pay, no matter what.

Edit: done — and I'd encourage anyone else who feels like they have benefitted from the project in some way to support this
Well, personally, find it very arkward that a company ask for donations... You have to decide. Be non profit and take donations, or be a company and earning money.

... it would be good to see something more accessible than a somewhat unusual (as in, from the norm) package install command in order to use it.

Hmm, well with the precedent established here and the increasingly embarrassing communication approach from the PIO reps, I can’t imagine this would be the last time a hardware company will refuse to officially attach their name to the project.
Installing support from external sources might just become the new normal instead!

From the horses mouth 🤭

Those numbers were for a point in time (a six month period in 2022), and not continuous. The availability of the BCM2711 chip was, unfortunately, not consistent as they had hoped, meaning the shortage got worse before it got better again (at least AFAICT from my conversations with them in late 2022 and through 2023). I know I probably sound like a Pi sycophant saying it, but I was in the same boat—I had ordered Compute Module 4s and a few Pi 4s in late 2021 and did not receive them until late 2023.

Well, personally, find it very arkward that a company ask for donations... You have to decide. Be non profit and take donations, or be a company and earning money.

Regardless, they did provide value to me, and I decided to repay them for that value. Hopefully they can provide more value someday, but I always try to support the projects that help me in my own work, financially if at all possible.

I'm sure there are ways to pass this PR if people would be more flexible and understandable. There should be a way of adding it to PlatformIO for easy (built-in) installation with the caveat that it's not possible to provide support at this moment. You can even point directly at Raspberry Pi with a message explaining why this particular platform isn't officially supported.
When more people will be using PlatformIO instead of the solutions that Raspberry Pi suggests, that might be a wake-up call for them. Honestly, I have no desire to install their Pico C SDK, and I'm sure there are lots of others like me. I have a lot of different boards laying around here, not just Picos.
If I had to go through an unique SDK install process and jump through hoops for each one, I would have just given up with electronics. It's because of Arduino and PlatformIO that we can use a single application and code base across a myriad of devices with ease.
It's partly because the official Arduino solution for the Pico boards kinda sucks that we're here. Everyone here prefers to use Earlephilhower's excellent core. It's a shame that everyone at the moment has to go on a search quest in Google to find out why their favorite core isn't there in PlatformIO and how to get it working. I still have some hope that we can work this out so simple users like me can easily install Arduino-Pico with PlatformIO, even if it has a huge banner at top saying "Not officialy supported, Raspberry Pi did not agree to the licensing".

It would have been much easier for everyone if RPi had simply gone into business with PIO, but now I can stand back and appreciate the smart decision. Not that RPi makes a habit of that or anything, but with some perspective they earned a little more of my respect at roughly the same rate PIO is losing it.

find it very arkward that a company ask for donations

In the 90's some dev products just didn't have hobbyist versions and an average person just couldn't afford to use them, even the box/OS cost was above what most could afford. Other companies used to have a specific "home" version of developer products that would allow limited use for a small fee. Fast forward to now, the donation model is pretty much the only way a small company can recoup even a small amount of its outgoings from hobbyist users. I look after a more niche product than platformIO, with maybe thousands of users, and I would say only a few percent donate.

I would like to thank Max and Earle for all the work that they have done on this. A lot of people are using it. Although it is a shame that it is not fully integrated, I can more than see Ivan's point about needing vendor buy-in. Otherwise, how do you support it long-term without a good relationship with the person making the framework?
As it happens, I've moved to CMake with PicoSDK, but for the times I need Arduino support during library testing (via Earle's core) it would be nice to have a middle ground somewhere. Could there be some kind of community flag in the repository? You could even have a flag that needs to be set in the env section of the INI file such as "allow_non_commercial=true". That way people could at least get easy access to it and it is still clear that it is completely unsupported.
If a crowd-funding page were created, I would most certainly contribute a small amount to it along with my yearly donation (which admittedly is quite modest). It would at least help with any ongoing costs. But admittedly, this does not solve the problem of long-term support which requires buy-in from Raspberry PI themselves.

Reduced default debugging and OpenOCD upload speed to 1000kHz, the 5000kHz was giving me verification errors.

PicoProbe works for me with 10MHz instead of 1MHz. A 1MHz SWD clock notably reduces debugging performance. Are you sure this is a software problem an not just an unreliable connection (e.g. cheap breadboard and jump wires, oxidized contacts)?

@geerlingguy wait where is the go fund me - I’ll match you.

@taf2 - I just used the donorbox link from their donate page: https://donorbox.org/donate-to-platformio-project

@geerlingguy done - now hopefully that helps - wish there was away to see how much is being donated towards this issue.

These guys have already stated unequivocally no to merging this, so why are you sending them donations? They want a income stream from a subscription I seriously doubt a few bucks will change their minds. Should send your donations to @maxgerhardt

@lsellens - I tried to find a donation link or GitHub Sponsor button but couldn't on @maxgerhardt's profile. Would love to throw him some support as well.
I am still fine supporting PlatformIO with a one-time donation because they have provided me value in the past, and I never really compensated them for that. Moving forward, it would be great if they would take the side of the community here, but if not, no skin off my back.
I try to support as many of the OSS individual developers and communities as I use as possible—typically I 'tithe' at least 10% of all my income every year to the dozens of OSS projects that have helped me earn it. I wish everyone would do the same. Not the least of which are corporations who earn millions or billions off the free labor of we individual devs :)

Thank you to everyone who contributed to this matter by making donations. Your donations (thousands of $$$) have all been refunded a few days ago. If you haven't received your money back, please contact us at<EMAIL_ADDRESS>Just a reminder - you've already paid Raspberry Pi Trading, the commercial company. You don't need to pay again. If there are any issues, Raspberry Pi Trading knows how to reach us.

Please avoid posting unrelated comments in this thread. Every time we separate the important information, it gets mixed up with various elements like stones or straw. Hopefully, this is the final clarification for those who don't grasp the connections between PlatformIO, Earlephilhower's Arduino Core, and this repository.
a) Earlephilhower's Arduino Core is an independent repository for implementing Arduino/Wiring API for RPI2040, designed for the Arduino IDE. It doesn't rely on PlatformIO, and vice versa. Installation instructions are provided here (https://github.com/earlephilhower/arduino-pico#installation). There are also guidelines on using it with PlatformIO through community integration.
b) This repository was created by PlatformIO Labs, a commercial entity that initiated and continues to maintain the PlatformIO project. Its purpose is to offer official support for Raspberry Pi Trading products (RP2040 MCU, Pico SDK, and various frameworks, including Arduino), along with free professional technical support. This can only be achieved through close collaboration with Raspberry Pi Trading.

Some individuals in this thread seem to harbor negative feelings towards PlatformIO. If you dislike a product, it's generally preferable to switch to a better one and move on. If you're persistently commenting without seeking mutual understanding, it implies:
a) There might not be a better solution than PlatformIO.
b) You actually like PlatformIO but are upset that this PR isn't merged.

The only solution here is to communicate with Raspberry Pi Trading. If they're not responsive today, it doesn't mean it will always be the case. They recently received an investment from Arm, and the views of investors and founders can differ. Even if someone personally dislikes PlatformIO, business decisions take precedence.
We'd be happy to reopen the discussion in this thread and collectively explore the initial steps toward achieving our common goal.

@ivankravets - Can you please close the PR then? It's patently obvious Raspberry Pi is not interested in paying to have the PR merged, and it sounds like PlatformIO will not merge it unless Raspberry Pi pays. So why is it left open, to give people false hopes?
I do like PlatformIO, I just think the decisions within and course of this PR's progression over the past 1.5 years is very rough and sad.

@ivankravets Nobody dislikes PlatformIO, we just want you to read the room. It's really that simple.

If people disliked PlatformIO then they wouldn’t bother coming in here to express disbelief that you would paywall a third party to prevent them from benefiting from another third party’s FOSS work, when 95% of the solutions you offer are FOSS you’re benefiting from in the first place.
The feeling is similar to discovering that your neighbor has constructed a barricade at the end of your public street and refuses to remove it unless the city pays your neighbor to fill some potholes. You can use another neighbor’s driveway to go around, but it’s inconvenient. And if you try to fill the potholes yourself to solve the problem, your neighbor digs them back up.

paying to have the PR merged

We don't charge anyone for PRs. Some individuals in this thread manipulated information to create hype without understanding PlatformIO and its business model. When a silicon vendor provides official integration to PlatformIO, PR review, professional integration, and support are all covered by the PlatformIO Labs team.

Can you please close the PR then?

We didn't open it. We value this PR and respect Maximilian's contribution. We still believe in a future where we have official support for RPi products, and this PR will be reviewed and merged.

when 95% of the solutions you offer are FOSS

Almost all our tools for end developers are free and licensed under Apache 2.0, aligning with our mission to democratize the embedded systems world. Every engineer with good knowledge in C/C++ should have access to free and professional embedded systems development tools.

neighbor has constructed a barricade

An inaccurate example; let's update it. We bought a large piece of land, developed unique technology, and built a modern housing district with developed infrastructure. Residents are content, sharing their happiness on social networks. Regular visitors come to the district for cinema, cafes, shops, etc. One day, a group of people organizes a mass picket asking, "Why is there no 'RPi' shop on the central street?" The answer is simple: Raspberry Pi Trading doesn't want to rent a place and showcase its products here. So, the question is, why aren't investors in this district opening the RPi shop and investing additional resources? Do they have official rights for this?

paying to have the PR merged

We don't charge anyone for PRs. Some individuals in this thread manipulated information to create hype without understanding PlatformIO and its business model. When a silicon vendor provides official integration to PlatformIO, PR review, professional integration, and support are all covered by the PlatformIO Labs team.

Can you please close the PR then?

We didn't open it. We value this PR and respect Maximilian's contribution. We still believe in a future where we have official support for RPi products, and this PR will be reviewed and merged.

when 95% of the solutions you offer are FOSS

Almost all our tools for end developers are free and licensed under Apache 2.0, aligning with our mission to democratize the embedded systems world. Every engineer with good knowledge in C/C++ should have access to free and professional embedded systems development tools.

neighbor has constructed a barricade

An inaccurate example; let's update it. We bought a large piece of land, developed unique technology, and built a modern housing district with developed infrastructure. Residents are content, sharing their happiness on social networks. Regular visitors come to the district for cinema, cafes, shops, etc. One day, a group of people organizes a mass picket asking, "Why is there no 'RPi' shop on the central street?" The answer is simple: Raspberry Pi Trading doesn't want to rent a place and showcase its products here. So, the question is, why aren't investors in this district opening the RPi shop and investing additional resources? Do they have official rights for this?

Are you really respecting Maximillian's work by essentially using it as a part of a carrot you dangle over Raspberry Pi Trading as the so called future you believe in?
Regarding your analogy of the RPi shop, there's the retailers program, so that fails. You can sell enterprise support for business people that want platformio working on the pi pico's embedded in their solutions, make your money from there and no one will bat an eye, Its what everyone does with stuff like CM4's wrapped in fancy industrial boards

When a silicon vendor provides official integration to PlatformIO, PR review, professional integration, and support are all covered by the PlatformIO Labs team.

I don't see anywhere in this thread (or elsewhere on the project) where Raspberry Pi Trading Ltd. ever requested (much less provided) official integration to PlatformIO. This has been a community effort to make it so software we like (PlatformIO) integrates with a hugely popular platform we like (Pi Pico), and the only time Raspberry Pi Trading Ltd. got involved—at least from any public record I can find—was when PlatformIO started a backchannel to try to get Raspberry Pi Trading Ltd. to pay up for support—which they never requested?
I could be wrong, but please enlighten us on this turn of events, where Raspberry Pi Trading Ltd is the villain here, asking PlatformIO to provide free support for their platform...?
This entire thread after a few months from the OP's comment has put a really bad taste in my mouth :(

I do fully understand how Platformio is acting here. Why should do they support and maintain work (and run infrastructure) which does cost money, for free? The company which would have a benefit from (Raspberry) is not willing to pay for this. Thats there free decision.
Normal business. No money, no service.  No bad guys on either side.
The work fork from Max and Earlie can be used, don't understand what people here are complaining about (btw. did something similar as Max to support Arduino 3.0.0 for espressif32).
Some people seems do not have understand Open Source does not mean does cost nothing.
There is no free lunch.

I'm pretty new to platformio and making in general. I'm doing a hacker box which is using the Earl repo.
How can I get the Earl repo installed into platformio to be used?
Thank you.

We've documented the install process in the Arduino-Pico documentation.

Out of all the jaw-dropping statements by @ivankravets this one stood out to me the most:

If Raspberry Pi Trading truly values freedom for their customers, they should have engaged in a discussion about the licensing fee.

And it looks like the same is now happening with Espressif support: https://github.com/platformio/platform-espressif32/issues/1225

Once we gather enough interest from the Espressif community, we plan to reach out to the Espressif company and request a reconsideration of support for PlatformIO.

Same situation here with RPi Ltd. Now that I have a better perspective I fully support Espressif and RPi Ltd and will move away from PlatformIO and focus on alternatives or forks. Sad.

If there are no code changes requested on this PR and you are still not going to merge it, then you should close it. Clearly Raspberry Pi are not going to pay you and I'd be surprised if they ever want to deal with PIO.

I've just recently got aware of this topic, as searching for running RP2040 over PlatformIO to support it over a framework H4Plugins with a prepared PIO environment H4Plugins_Env.
I know this thread is full of words and statement, I understood everyone's perspective, developers, PIO, and RPI.
What I'd like to say here that we (developers) owe PlatformIO a lot, great IDE with great experience, unifying everything for us to a single place.
Which is the thing that PIO had invested in: Make it totally free to developers. But we need to see the whole image.. I mean, they don't sell data as Google and Facebook, neither running ads to get revenue. Here I understand where they monetize from: The silicon manufacturers.
Yet also me don't like that resulting in absence or lack of support to some popular MCUs, but I should also respect that decision.
Now I'll check how to run RP2040 over PlatformIO even with non-standard ways (as it's available AFAIK), but I'm not ready to consider other IDEs, except for very serious reasons.
The best solution I see is that RPI and PIO agree on a fair deal.

Eben Upton wrote:

We received a proposal from PlatformIO Labs in October 2022. While we absolutely empathise with the challenges of funding open-source projects, we were unable to justify paying the very substantial recurring fees involved. We indicated that we would not be proceeding, and have subsequently made some investments elsewhere, notably in the Raspberry Pi Pico Windows Installer.

Now that is ... beyond imaginable.
PlatformIO, a minuscule company (in terms of finance) compared to Raspberry Pi Ltd and nanoscopic compared to Microsoft is being refused financial support.
It's Raspberry Pi Ltd investing in.... developing tools for use on the mastodon Microsoft platform Window$ !
PlatformIO works perfectly on M$Window$.
The world is upside down...
Couldn't have the folks at PIO and RPi Ltd come to an agreement? If it's too expensive then talk!
If we, users, voted for which solution we'd like, the Windows installer or a RP2040 (pico and other boards) integrated in PlatformIO, I am overly confident the later would come out first.
Right now we all lose:

users still don't have proper support for the RP2040 chip in PlatformIO
PlatformIO didn't get anything financially from Raspberry Pi Ltd,
Raspberry Pi Ltd invested in a tool gathering only 240 stars on github (vs 7.7k for PlatformIO core only) and last updated in 2023 as of writing, and the RP2040 competitor, Espressif, benefits from PlatformIO immense capabilities.

Who is happy to observe the argument? Well... certainly Espressif, and in fact, they don't even need to care.
Come on PlatformIO and RaspberryPi Ltd... make up the disagreements, you both have a lot to earn from working together one way or another.

This situation is not primarily a financial issue. Raspberry Pi Trading Ltd. is a publicly traded company with a market capitalization exceeding £750 million. You can find more details on their financial standing here: Raspberry Pi Holdings on London Stock Exchange.
What we're seeing is a classic issue in the semiconductor industry: the larger the company, the wider the gap between its customers. Often, company stakeholders rely on input from their technical teams, who believe they understand what embedded developers need in terms of development tools and IDEs. However, these teams frequently prefer legacy tools developed decades ago, assuming that all embedded engineers should adopt these outdated tools and workflows. Unfortunately, this approach often neglects the actual developer experience, focusing more on chip sales than on the quality of development tools.
Raspberry Pi Trading Ltd. is not unique in facing these challenges. Public statistics highlight similar trends across the industry: Embedded Development in VS Code Statistics.
Many excellent projects have faltered due to this disconnect between stakeholders and end customers. For example, consider Arm Mbed OS, which was a promising project before Arm acquired it. You can read about its decline here: End of the Line for Arm’s Mbed OS.


Exclude ncbi_taxonomy from db adaptor list

It would be great if you could cherry-pick this for branch release/82 also


How can we add dynamic frequency based on job runs

Is it possible to change the frequency of the job, based on some job handlers ?
our app is fetching location based on users current location,  if user is near to some destination location we need pool the location frequently. if not we have to increase the job running time,

Yes, you can just run schedule again with another period.

we can run same schedule in job method only ?

I don't understand the question


How to trigger hook based component from vanilla Javascript DOM script.

Hello,
Can you address this issue using React Hooks?
https://stackoverflow.com/questions/66762339/calling-react-function-based-component-from-vanilla-javascript-dom

We use this issue tracker for bugs, features etc related to the React docs. Support questions often go unanswered so I encourage you to wait a bit for the answer on StackOverflow or try another support channel listed on https://reactjs.org/community/support.html


Seemly bugs found in npbench code

Hi, as I was working with npbench recently, I have found the following seemly bugs:
cholesky
Code: https://github.com/spcl/npbench/blob/857a7ec2d267e255bfcd9bad296be1cbf4e81178/npbench/benchmarks/polybench/cholesky/cholesky_numba_npr.py#L10-L13
Line 10 is a prange, but actually this loop is not parallel due to the data dependence on A[i,:j]. To correct this nb.prange should be just range.
I also noticed that for this loop Numba (most recent version) seems not compile to nopython mode with @nb.jit(nopython=True, parallel=True, fastmath=True), but removing parallel=True gets the code compiled to nopython mode.
Also the validation for cholesky always passes no matter what. I support it could be due to that the kernel function doesn't return anything.
Actually not just cholesky doesn't return anything, many other benchmarks as well, like syrk etc. So they may also always pass validation no matter what.

Hello! Thank you for reporting these issues.

Line 10 is a prange, but actually this loop is not parallel due to the data dependence on A[i,:j]. To correct this nb.prange should be just range.

Good catch; the prange should be on the outer loop.

I also noticed that for this loop Numba (most recent version) seems not compile to nopython mode with @nb.jit(nopython=True, parallel=True, fastmath=True), but removing parallel=True gets the code compiled to nopython mode.

A version with parallel=False is already included, but we will also fix the one with the erroneous parallelization.

Also the validation for cholesky always passes no matter what. I support it could be due to that the kernel function doesn't return anything.
Actually not just cholesky doesn't return anything, many other benchmarks as well, like syrk etc. So they may also always pass validation no matter what.

There is functionality in the benchmark that allows marking kernel parameters as both input and output. These parameters are also validated. Cholesky's A parameter is marked as such, but there may be some other bug that breaks validation in that case. We will investigate.

Thanks a lot for confirming!


Help me find a better name

I have been told repeatedly that osmf is an unfortunate choice of name, because OSMF is used in the community to refer to the OSM Foundation. I should thus probably rename the tool. Who's got some ideas or opinions on a better name?
Here are some ideas I already discarded:

osmq (q for query; already taken)
osmfind (a little too long for my taste)

Here are some more ideas:

osmr (maybe a bit too generic)
osmfd
scout
spotter
gleanr
descry
espy
loc8
ambit

OSM ZOOM (OSMZ)

omgosm

Hi from the OG OSMF. Good luck with your interesting project, I'm looking forward to trying it once the name isn't as confusing :)
My /usr/share/dict/words has quite a few words that contain 'osm' - too many to spam github issues with. I'm surprised no one has ever used 'cosmo'. To bounce off Piotr's idea, I'll also suggest 'zoosm'.

Good idea @grischard, thanks! I hadn't thought about trying the "smb/samba approach". There are definitely some interesting names in there, like "osmate" or "osmin".

browsm

exposm
(too bad "explosm" is already a thing)

I have now settled on "osmar" and published https://github.com/codesoap/osmar/releases/tag/v2.1.0 with the new name.


Initial scope implementation.

This is an initial implementation to support scopes for the
Java language bindings. It currently provides only hierarchical
name scopes.
Please see https://github.com/tensorflow/tensorflow/issues/7149
to track the master issue.

Can one of the admins verify this patch?

@Moriadry thanks! I've started an informal group to find out who's working on what in this particular area, and consolidate efforts from interested people - we can continue the conversation there.

@kbsriram Got it, I already submit a request to join, many thanks!

Gentle ping - could a member wake up the test this please ci bot?

Jenkins, test this please!

The single test failure (//tensorflow/python:basic_session_run_hooks_test) looks unrelated.

Jenkins, test this please.

Broken Mac test rebuilt here: http://ci.tensorflow.org/job/tensorflow-pull-requests-mac/5318/console

Broken Makefile test rebuilt here: http://ci.tensorflow.org/job/tensorflow-pull-requests-makefile/9172/console

Broken Android test rebuilt here: http://ci.tensorflow.org/job/tensorflow-pull-requests-android/5321/console


support for dotnet based projects

@dplabsindia, Thank you so much. Could you add some repotests as well?

[ ] Run npm run lint command to resolve biome issues
[ ] Needs unit tests and a repo tests for .Net framework

@durga-pasupuleti Are you planning to implement the PR comments, so that we can include this in 10.6.x?

Yes Prabhu. Today i will push them
On Mon, May 20, 2024 at 14:40 prabhu @.***> wrote:

@durga-pasupuleti https://github.com/durga-pasupuleti Are you planning
to implement the PR comments, so that we can include this in 10.6.x?
—
Reply to this email directly, view it on GitHub
https://github.com/CycloneDX/cdxgen/pull/1088#issuecomment-2121083444,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFK723RD2BRXUZSNQI6X4HTZDJGTTAVCNFSM6AAAAABH3F5NZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGA4DGNBUGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Could you kindly follow the instructions mentioned here to sign your commits?
https://github.com/CycloneDX/cdxgen/pull/1088/checks?check_run_id=25230419605
I think we are very close to getting this tested and merged!

Could you kindly follow the instructions mentioned here to sign your commits?
https://github.com/CycloneDX/cdxgen/pull/1088/checks?check_run_id=25230419605
I think we are very close to getting this tested and merged!

I have added signoff by following the steps and added repotests. Anything i can do from my side.

@durga-pasupuleti, Thank you for this PR. It gave me the idea about what is missing. Let me collect some more examples and reimplement this slightly differently.

Superseded by #1119. Thank you so much for your guidance.


Signed int key benchmarks

Just an exercise to confirm the different methods of doing to-cw-bytes are not incurring a significant performance loss.
Not sure this needs to be merged. Published for reference.

I wonder if there's some feasible way to present those results in good way? Criterion prints a lot, and I personally use CircleCI as rare as possible.

You mean, besides cargo bench default output? There a number of options for displaying results (see https://doc.rust-lang.org/cargo/commands/cargo-bench.html#display-options), but now sure how to use them.
That said, -- --output-format bencher produces a terser output.


TST: reduce max memory usage for sparse.linalg.gcrotmk test.

Closes gh-9595
This test calls np.random.choice with a large sparse array of shape
(10000, 10000). Under the hood, choice ends up constructing a dense
array of the same size explicitly, in np.random.permutation. That
takes 0.8 GB for int64. That then goes on to np.random.shuffle, which
creates some extra buffers. The MemoryError seems to be simply because
we're pushing the 2 GB limit on 32-bit Python.

Thanks @rgommers