Learning more about why these awesome plugins arent on the hub (yet)

[LCObus]

@haesleinhuepf this is really interesting to review, thanks for putting together! I and folks on the hub team are curious as well, and want to do a little interviewing to learn more about why folks aren't publishing on the hub and how might we support them along the journey. My early hunch is "not on hub" plugins fall into the following categories:

1. active development/ not yet ready for publishing widely (everyone is at this stage to start!)
2. active development/meant for a constrained audience (deliberate internal use- don't want distribute beyond lab/group)
3. depricated/abandoned plugins (but potentially has resuable code)

Curious- do you have any additional categories you think we should add? I love your goal to help folks use the code and resurrect functionality. Our goal is to reach out to a handful of these plugins and learn more about why they haven't put it on the hub. we have strong hunches about our ability to add functoinality that supports at least #2, but may help with your goals for #3.

[haesleinhuepf]

Hey @LCObus ,

great to see you here! Yes, I would be interested in mid/long-term perspectives of plugin on/off the hub. You know, many PhD students develop something cool, release it when handing in their thesis, and afterwards abandon it. I'm wondering if folks have plans for their plugins and if there might be support (funding, community, institutional, ...) they can rely on to develop napari plugins sustainably. I did a little brainstorming with Pixel and we came up with these thoughts:

The plugin's future directions are

• None
• Maintain for 1 or 2 years (e.g. until my current contract ends)
• Maintain for many years (e.g. because my own career relies on it)

In the same context, it is interesting to know who plugins are made for:

• I made it for myself to enable my own research
• I made it paid by my institute to enable research at the institution I work for
• I made it to enable research of my collaborators
• I made it to enable research of scientists world-wide

This leads to the question, who will maintain a plugin mid-/long-term:

• Nobody
• Myself, also if I move on to another institute
• My group leader and/or other group members, because I made it for them
• A group at my institute, e.g. because the tools is of strategic interest for the institute
• Community of open-source developers

I'd also be curious what roles the plugin developers in the napari community play

• Napari core developer
• Napari code contributor
• Napari community member (occasionally attends community meetings)
• Active in related communities (scikit-image, vispy, jupyter, conda, ...)
• Not connected to the community

... and the job descriptions the plugin developers have

• [Bio]image analyst
• Research software engineer
• Researcher (PhD-student, postdoc, PI)
• Staff scientist
• Core facility engineer

And of course, the funding question: Plugin developers are paid by

• University / Research institute core funding
• Public funding agencies / research grants
• CZI Napari plugin accelerator grant
• Company
• Not paid for developing napari plugins

I'm not sure if you will run a whole survey, I'm just thinking loudly about the aspects that might play a role when it comes to deciding if/how/when a plugin should show up on the napari hub.

[LCObus]

these are great questions! I'm curious what how knowing the role in community and job description would help you understand plugin motivation- the rest you basically read my mind on :) I'd also want to add a multi-select and/or open ended question around what we could provide that would better support where one's plugin shows up and is used (ex: create and distribute plugins as zip files/wheels).

The emerging plan is to reach out to a selection of these plugins (including some on your list) and prime with a short survey (ill happily run with these if you're okay with that!) and offer the ability to have a follow up convo if they're keen. The research goal is better definition of why folks are choosin not to add to the hub and potential features we could build that would improve the user experience (private sandbox so cores can share internal work/data, more targeted ways to resurrect that useful functionality you point out, etc)...

[haesleinhuepf]

I'm curious what how knowing the role in community and job description would help you understand plugin motivation

Hypothesis: The closer you work with the community, the more likely it is that you upload your plugin to the hub and maintain it long-term yourself. Multiple reasons: The community is great. If you know it, you want to contribute to it. Furthermore, if you see how decisions are made in the community, you can get a feeling if your plugin can survive there. Just a crazy example: Imagine a community which develops a tool in a super chaotic way, where backwards compatibility breaks all the time, and decision making is zero transparent. Would you mind developing a pluign for this tool? (-:

The job-description is interesting, because I spottet quite some core-facility/research-software-engineers among the plugin authors. However, many of these core-folks do not often interact with the napari community (at least to my knowledge). I conclude they started exploring napari for other reasons, community-externally triggered. I suspect institute/core-facility heads asked their engineers to explore capabilities of napari and its plugin-system. Many plugins appear explorative (can we use it for our research). From that group it might be interesting to hear, why the plugin-development halted (if it halted).

why folks are choosin not to add to the hub and potential features we could build

Great goal! I suspect though that reasons are not so much releated to the napari-hub or pypi (I'm happy to be proven wrong!). I suspect it's more personal reasons such as "If I put it on the hub, it'll be exposed to the public. Then, I have to support it / answer user questions / fix bugs. And I'm not paid for that / have no time for that."

ill happily run with these if you're okay with that!

Sure, consider my thoughts written above cc0-1.0 licensed :-D

[LCObus]

Thanks for clarifying! We are going to run with a set of these questions in survey form to a group of plugins (including some from your list!) and also include the option to chat in a followup interview. I'll keep you in the loop about what we find- thanks for getting this started!

[LCObus]

sharing a quick(ish?) update for you!

• light participation (4 surveys completed, 1 conversation) after 1 email nudge
  • mitigation: hold on publishing on social due to other factors in community
  • Justin may have additional outreach candidates
  • Move to outreach to Chi-li’s experimental plugin candidates (ie plugin that have been published, but might benefit similarly from potential additional features that a "yet to be published" will)

Takeaways:

• plugin goal: majority to enable research world-wide (motivated)
• maintenance: No one definitively knows their maintenance runway (either “depends on factors” or “2+ years”)
• who does maintenance: expects community of open source to maintain long term
• Responses are WIDELY diverse, may represent distinct use case buckets:
  • "missing a core feature": conda dependency (FEATURE NEED)
  • “limited use case”: meant for specific collaborators, no longer maintain, don’t want broad maintenance burden (SANDBOXES)
  • “not ready yet”: young developer, weary of changes to napari codebase (SANDBOX)
  • “It’s evolving/I’m building something better”: a “legacy” plugin, updating for lighter weight, more modularity- will deprecate, but didn’t want to overburden details page to inspire modularity (“inherently vague plugin- this respondent made a lot of points similar to yours regarding reuse of plugin parts!")
• next:
  • explore a case for sandboxes as a bridge to publish? an experimental flag?
  • fear of napari not ready yet/incomplete features
  • a case for workflows
  • continue quality nudges for plugin page

[haesleinhuepf]

Thanks for letting me know @LCObus that sounds indeed interesting. I'm looking forward to when the napari plugin grant period ends. I'm expecting a bunch of new plugins arising and hopefully also plenty of feedback from the developers of those plugins. :-)

[LCObus]

I'm looking forward to that period as well! We've got two additional studies that are somewhat related to this inquiry:

1. identifying community plugin quality standards (see tweet and github discussion here: https://twitter.com/ObusLucy/status/1516185890065993736 , https://github.com/chanzuckerberg/napari-hub/discussions/463, your feedback always welcome!)
2. interviews with hub end users to understand current hub experience, plugin searching vs exploratory evaluation, and collections concept testing. Would love for you to share with any researchers you're connected to! sign up here: https://calendly.com/czi_imaging/napari-hub-interview?month=2022-05

I'm excited to learn more about how we can support plugins at different stages/iterations!