Understanding why Github project being archived

General
1

Hello everyone,

Thanks for this great project ! :grinning_face:
I’m opening this thread just to understand better why all source pages are being archived since early 2026.

It seems counterproductive from a community perspective, as it implies the community driven part of UC2 is to be slowly deprecated. Don’t you fear that this choice might alter the initial vision of your project ?
What is the rational behind this choice ? Is the OSH model really placing the business entity at risk ?

I’m myself the founder of an open hardware based company (with a similar Business model, but for power electronics), so I know the struggle, and I totally understand if it can’t be discussed publicly, but I’m genuinely curious of what is driving this hard choice.

2

Hi! This is Ethan - I’m the (relatively new, having joined in September 2025) software engineer at openUC2 who archived a bunch of repositories in openUC2 · GitHub last month; before joining openUC2, I was involved in the open-source PlanktoScope community both as a user and as the (stopgap) volunteer lead maintainer for the software in PlanktoScopes.

Archival of unmaintained repositories

I’m very excited to hear your expression of interest/concern about some of openUC2’s 120 public repositories, beyond the ~20 public repositories which we’re actively working on (and which I’ve left unarchived, because we need them to be unarchived in order to make new commits!). Of the ~100 repositories which are archived in the openUC2 organization (i.e. ignoring the 32 additional repositories in youseetoo repositories · GitHub , only three of which appear to be active), and almost all of which were archived by me in a bulk operation using GitHub’s API, this is my impression of their status:

  • Repositories which look like archival materials:
    • 2 (ImSwitch-ReactAPP and imswitch-os) were manually merged by me into other repositories (ImSwitch and rpi-imswitch-os, respectively) in order to reduce toil in making coordinated changes.
    • 1 (imswitch-arkitekt) appears to have been abandoned in favor of a subsequent repository with a clearly related name (imswitch-arkitekt-next)
    • 25 (openUC2-SEEED-XIAO-Camera, openUC2_SOOP, openUC2-Safety-Docs, UC2-Spectrometer, UC2-Motorized-XYZ-Micromanipulator, UC2_DornaGripper, UC2-STEP, UC2-Light-sheet, UC2-Hi2, UC2-OpenFlexureStage, UC2_openSIM, UC2_Feather, UC2-Workshop, UC2-Zstage, UC2-MultiColour, UC2-Motorized-Rotator, UC2-MicroSyringePump, UC2-Motorized-XY-Table, UC2_Fluorescence_microscope, UC2-Holo, UC2_openISM, UC2_OpenFiberCoupler, UC2-Ptycho, UC2_openKOEHLER, UC2-MicronStage) appear to be documentation packages produced by openUC2 which are now unmaintained (most of them unmaintained for years!), or are de facto “done”/“complete”, or were abandoned years ago in favor of continued development in some other repository (though because there’s an overwhelming number of repositories and a lack of any READMEs notices about movement to other repositories, it’s hard to tell which repositories might be continuations of that work!).
    • 11 (pi-camera-in-docker, openODMR, cubelab, microEyeUC2, ashlarUC2, ImSwitchNode-Planktoscope, cookiecutter-napari-plugin, ImSwitch-fastapi-gui, napari-live-recording, UC2_microstepper_kinematicmount, UC2Shield) were forks of upstream repos which appear to have been made for prototyping/experimenting, but which I think are no longer practically useful
    • 7 (openUC2-Hackathon-BluFocus, Hackathon-UC2-LLM, openUC2-Hackathon-openOCTRemote, openUC2-Hackathon-HistoScanner, openUC2-Hackathon-GOSH, openUC2-Hackathon-SampleRecorder, UC2-Hackathon) appear to be experiments/projects/prototypes/demos/starters made for hackathons but not carried forward for subsequent maintenance
    • 18 (ImSwitchInstaller, openUC2_MultiCam, ImSTORM, openUc2MicroManagerDeviceAdapter, imswitch-lightsheetopenuc2-dorna-control, Arkitektrons, ImSwitchWorkflowManager, ImStitch, openUC2-OT2-PlateGripper, openUC2-ESP32InfoScreen, ut2_module, imswitch-sim, imswitch-flimlabs, UC2-STORM-and-Fluorescence, openCM2_hardware, openCM2_software, uc2-configurator, UC2_ISM_CODE) appear to have been past experiments/projects/prototypes (mostly - but not all - initiated by Bene) which have not received any further interest or attention or development/maintenance activity from anyone, as far as I can tell.
    • 3 (openUC2-Extensions, UC2-ImJoy-Plugins, UC2_OFM-extensions) appear to have been made as collections of plugins/extensions/addons have gone unmaintained for years. It appears that Benedict was the only person who had ever added plugins/extensions/addons to those repositories, so they hadn’t ever been community projects.
    • 2 (openUC2_esptool_docker, imswitch-pi-gen) were definitely Bene’s own experiments which definitely are no longer practically useful
    • 3 (UC2_project_template, UC2-Module-Template, UC2-Basehelper) appear to be template repositories which haven’t needed further development, whether in theory or in practice
    • 1 (ImSwitchInstaller_OLD) has a repository name which suggests that it is not meant to be used anymore
  • Repositories which look like cruft:
    • 11 (imswitch-imager, react-file-manager, mmCoreAndDevices, micro-manager, pi-gen-imswitch, lumencor_Spectra_X, cheap-xy-stage, Marlin-2.0.9.6, UC2-waveguiding, open-hardware-site, installLXDE) were forks of upstream repos which Benedict had forked but never committed to, so they have no value except perhaps as an archival copy of someone else’s project in case the upstream repository gets deleted.
    • 12 (ImTools, imswitch_lightsheet, UC2Serial, openUC2-Lightsheet, openUC2-FiveD, openUC2_MicROScopy, EspresssoscopeSpiral, uc2-control-android, openUC2_XYZ_Stagescanning_Microscope, UC2-ESP32SerialCam, UC2-openETL, UC2-RESTPiCamUC2-AR-APP) were apparently never significant/useful/valuable enough for anyone involved to have cared enough to spend any time to write a README for them
    • 1 (openUC2-CE-Certificats) is basically an empty repository
  • Repositories which had been archived as part of my bulk archiving operation for repositories which hadn’t been touched since ~August 2025, but which might not entirely be dead/abandoned/no-longer-used:
    • imswitch-arkitekt-next
  • Important repositories with community activity which had been archived before I joined openUC2:
    • UC2-GIT
  • Important repositories with a small amount of community contributions which definitely have already been de facto abandoned for years in favor of a different software architecture/approach/design:
    • UC2-Software-GIT

My rationale for archiving these repositories is that they all appear to be unmaintained, and

  1. having 100 repositories all be “live” (i.e. not marked as archived) makes it more intimidating for new people to approach the project to understand where their contributions would be practically useful (and here I’m speaking from personal experience both before and after I joined openUC2!); marking stale projects as archived makes it easy to filter to only select active projects which anyone is working on, for a less overwhelming view of openUC2 repositories · GitHub .
    For me, it’s like the difference between having years of papers be spread all over my desk versus having just the papers I’m working on at my desk, and all other papers stored in a box next to my desk. We already have so much technical debt and dead code in our current software that all this this additional “dead code” (spread out across 100 repositories) in inactive projects becomes yet more mental clutter if it’s not clearly marked as abandoned.
  2. I think it’s important to be transparent about repositories which currently nobody at openUC2 or the community is actively maintaining or supporting (and thus repositories where new issues or pull requests will not receive attention). Being clear about this helps to set clearer community expectations about each repository.

By being more transparent (via the “archived” status) about the current reality that the above-listed repositories already aren’t receiving attention or community involvement, I think it provides additional clarity to other people (who might want to take those repositories forward) that they’re free to make forks for their own further development. At least in the corners of open-source software development (particularly as a user of Go modules in the modules ecosystem for the Go programming language) which I was involved in before joining openUC2, this was my understanding of the assumed cultural convention for the meaning of GitHub’s “archived” repository status.

If/when we find that there is interest (either within openUC2 or in the broader community) for resuming development & maintenance of a particular repository, that would be a great time to discuss options for un-archiving that repository or even for transferring ownership of that repository to somebody else. Or, if we determine that there are particular repositories which I actually shouldn’t have archived in the first place (e.g. perhaps imswitch-arkitekt-next actually isn’t complete/done/finished, despite not having had any commits for 9 months), I’d be happy to immediately unarchive those repositories when needed - since it’s extremely easy to archive or unarchive a repository.

Community-driven & OSH aspects of UC2

Because my focus area is specifically in a subset of the openUC2 software (and because Benedict has been so occupied with a large backlog of quality improvements for customers who need to rely on the software we provide them that he hasn’t yet had time to draft a design note about the vision, principles & values which should guide openUC2 as a company and which should guide how we approach decisions related to OSH and community focus), I can’t speak authoritatively to the hardware-related aspects of openUC2’s overall vision regarding the concerns you raise about our intended relationship to the OSH model and a community-oriented approach to development.

My tentative impression is that our highest priority is to deliver working systems which are easy for our customers to operate + modify/reconfigure/customize/evolve + maintain in whatever ways they need, so that they can do whatever they need to do. This requires that our systems must be very transparent and reproducible for our customers. To the extent that community involvement in system design/development contributes towards that goal, I think we will work to support such involvement - e.g. we envision an easy way for people to extend the software, both as developers and as end-users, which means we need to facilitate an open ecosystem for arbitrary software recomposition+extension+replacement. But to be realistic, we currently have a long wishlist of technical & documentation improvements we need to complete in order to deliver on our vision of deep customizability for users with a wide range of technical fluencies. And, as far as I can tell, community-driven development specifically for the sake of community-driven development does not appear to be a high priority for openUC2, even if our vision does include community involvement in development towards a shared goal of creating something better for our customers.

Specifically addressing openUC2’s software repositories (since that’s what I can speak to), the first priority at openUC2 for our software is to pay off a ton of technical debt, bring a bunch of accidental complexity under control, and create a lot of documentation which is either missing, too difficult to find, or too difficult to understand. Currently, these issues make it prohibitively difficult for anyone (whether inside openUC2 or outside openUC2) to contribute to significant portions of the software. Until we (openUC2) clean up these problems, I don’t think it will be realistic for us to expect anyone to contribute to the software we maintain.

In the meantime, I think this is an important time for us to hear from people about what kinds of expectations around community involvement and OSH-ness would need to be met in order for what they get from openUC2’s projects/products to be so useful/empowering/etc. that they would be willing to support (whether through time or other resources) the continued maintenance of the things we maintain as open-source projects. For example, what would be helpful to you about openUC2 having a more community-driven emphasis in our approach to technical development? And (so that I can bring your input into future conversations in openUC2 about OSH considerations, where I would like to advocate in favor of a high level of transparency in openUC2’s future hardware+software products) what is important to you about having openUC2 products which come with editable hardware source files (which are done in Autodesk Inventor for mechanical parts and KiCAD for electronics) and not only hardware fabrication files or editable software source files?

3

Thanks @ethanjli for the detailed answer :grinning_face:

I completely share your view on the need of organizing content in a way it shows clearly which project one could contribute to, and how you can lower the friction from early interest to first meaningful contribution. Organizing a repo that contains Software, electronic hardware, and regular mechanical CAD is a huge task for sure.

Also agree on this principle of reality, where a company has to supports and improve their products to deliver proper products and fulfill customer needs, and sometimes it is a bit in contradiction with the open source world that tend to be a bit fuzzy… and sometimes chaotic !
I guess one of the way of sorting out what matters most to people on Github are… stars. This system is far from perfect, but it clearly shows which project get most notoriety and interest from the community. In the case of OpenUC2, one repo is skyrocketing (UC2-GIT), yet is archived.

From a foreign perspective, it kind of gives the impression that the community version of the product is no longer maintained and will eventually fade out, that you can’t contribute anything back upstream, so there is no point dedicating time trying to share back any new UC2 compatible modules, and that the only way to get involve is through regular customership.

That’s why I think it is important to let the chaotic open source door open, at least for the main repositories that get significant interest from the community, so that anyone can still deliver feedback through issues, propose enhancement through PR, and so on. This peer review process is one of the biggest strength of a community driven product IMO.

From a different perspective maybe GIT for CAD is not the way ? One of the most “successful” mechanical modular ecosystem is gridfinity, which is complete chaos, spread out in different open generators, proprietary 3D printer vendor clouds and so on, yet manage to deliver tremendous value to people with accessible, reproducible grid system for organizing virtually anything.

It that way is there a world where UC2 could be the “gridfinity” of optics ? Where a share of modules are commercially distributed by your company, but where the grid system can still be enhanced by everyone to get more & more add-ons over the years ? In that scenario, is it best to decentralize completely, or, you guys should aggregate that value in a way that Chaos is still kindda glued together by a Core team ? (you guessed it, I would advocate for the second option :wink: )

4

Thanks for your thoughtful reply! Two of the topics you raise (the UC2-GIT repo’s archival and trying to use Git for CAD collaboration on openUC2 designs) are ones which I don’t have much context/information about, so I’ll tag @benedictdied here :slight_smile:

Your third topic (about growing a coherent ecosystem through a good balance/combination of centralization and decentralization) sounds like something which Bene has been prototyping (as described at OptiKit: Building the Digital Backbone for Modular Optics - openUC2 ), and which we will be spending a lot of time to develop this year and next year.

I believe the vision is that anyone will always be able to develop new add-ons with the same cube/grid-based architectural standard (whose documentation currently lives at openUC2 Template for your own Insert | openUC2 Documentation , but note that I am in the process of reorganizing the docs site so information will be moved around and URLs will change), but I don’t know any deeper details of the open-source direction for the cube system - so I’ll hand this topic off to @benedictdied , too

5

Thanks for the great discussion @jalinei ! I’m curious, would you be up for contributing something to the openUC2 platform - and if so, what would be the best way to do it? I’m by no means an expert and always look for the best way to grop the community somehow

6

Not just yet, but I was envisioning using UC2 to create my makeshift optical bench to play around with laser diodes and open source beam profilers.

My end goal for this project would be to check the focusability of cheap power diodes under high pulsed power conditions (https://www.youtube.com/watch?v=3-htF8Jrixo&t=173s).
I fell in a curiosity rabbit hole, where I really want to check how not gaussian the beam will become, and wether we could potentially reach fluence conditions of some metals with regular diodes even if at ridiculously low pulsing frequencies (1xxx to 10kHz) with lowest possible spot size.

I read many things on beam shaping and so on, but I have no practical skills yet, so I was looking for a way to have a bench and few flexures to align things properly.

If along the way I create new modules or modify existing ones or if I do anything mentionned here : UC2-GIT/CONTRIBUTING.md at master · openUC2/UC2-GIT · GitHub , I will be more than happy to share back (and actually the OHL licences does force me to do so theoretically).

7

This sounds really interesting. I have absolutely now clue where to start to be honest :wink:

What are the reads you have been following so far?

One thing we would like to support in the near future is a simplified integration of external ideas into our cubes. We are preparing this in our openUC2 configurator. Do you have wishes how this should look like? :slight_smile:

image
image3144×2112 464 KB