Theme F: Visibility, community and partnerships

What it is

The cluster of concerns around PyScript being under-known, feedback being hard to give, and community contributions not always being honoured. Marketing is part of it, but trust is the larger part.

What it means for PyScript

Practitioners raised visibility unprompted, again and again, and often with a note of puzzlement or frustration. Kattni, an educator, called marketing "a perennial problem" and pointed out that PyScript "really does fill a gap" that people simply do not know exists. Nitau, an engineer, found it "mind-boggling" that PyScript is not "incredibly viral," arguing it should sit in the same mental list as React, Vue and Svelte. The channels people named are specific and consistent: video content and YouTube/Twitch (Łukasz, Claudiu), sharing platforms like CodePen (Mark), and LLMs (Theme E).

Two more uncomfortable truths sit inside this theme. First, feedback channels are effectively invisible to users. When PyScript.com crashed, Anna, a learner, "basically walked away," told no one and filed nothing, and was unaware of any feedback route. Hammad, an educator, assumed the fault behind the problems was his until we spoke. If our most engaged users do not know how to tell us something is broken in PyScript.com, we are flying blind. Second, Anaconda has not always honoured past contributions. Claudiu produced a professional marketing proposal that segmented the audience and set out an approach, and "nothing came of it," with no alternative direction offered despite an Anaconda architect being explicitly asked for guidance. Nicholas offered a direct apology in the interview.

Mark's CodePen idea is the most concrete partnership opportunity: approach CodePen about running MicroPython (and PyScript) in their environment, learning from the earlier Vue integration, so that "every example that you make, you put on CodePen" and draw people in who do not yet know PyScript exists. More generally, put PyScript where the practitioners are already found rather than on a relatively little-used website (i.e. PyScript.com).

The Tufts case study is the positive counterexample to this theme's harder truths, and may be a good future model. Rather than an invisible feedback channel and an ignored contribution, the two Tufts calls show the engagement loop working end to end: requirements gathered on a recorded call precisely so "folks can see how we've moved from a requirement to a solution," a proof of concept (TuftsHub) built quickly in response, a review call to refine it, and then a deliberate move to open the work up, keeping the repository under the Tufts GitHub organisation and asking Chris to raise future requests as public GitHub issues "rather than private Slack messages, so the wider community could take part." That is exactly the inclusive, in-the-open collaboration the rest of this theme argues we have too often failed to sustain. The lesson is that we already know how to do this well; the task is to make it the norm and mitigate future self-inflicted and thoughtless community faux pas.

Future steps

Build a sustained community-engagement and content strategy, weighted towards video and towards the LLM channel, rather than one-off pushes. Make feedback routes visible from inside the product itself; Anna's own suggestion for hearing about new things was an in-product banner on PyScript.com, "something I would definitely read," since she ignores email. Pursue a CodePen partnership and look for similar amplifying partners. Re-engage deliberately with contributors like Claudiu so that offering help to PyScript is visibly worthwhile. And treat the Tufts arc as a template for how requirement-to-solution work should run: recorded, in the open, and refined with the community.

Standing across archetypes

Visibility is felt across the board. The feedback-channel gap is most visible among learners and quieter educators; the honouring-contributions point is most acute for the hobbyist and administrator-leaning contributors who give their time without being paid.

Challenges

Repairing trust requires sustained cultural change in how Anaconda engages with open-source contributors, and that change is for Anaconda to own and act upon. The evidence of the cost is in this theme's body: a professionally prepared community contribution was ignored despite explicit requests for guidance, and the community contributor walked away in frustration.