· Sep 12

Quality of Open Exchange packages

I've been running my review collections on OpenExchange now for more than 3 years.
I explained the principle I apply in a past article
These reviews are the first step of the quality check in OEX.

My personal Credo
My expectation of OEX  (expressed in extreme) is to see it rather as
a collection of jewels, than just a flea market.

I start this discussion encouraged by @Evgeny Shvarov in his recent comment 

The quality of Open Exchange is very important, of course! 
And we have a set of features and processes are intended to understand 
and improve the average quality of projects. And as OEX is a living 
mechanism it is not possible to "click" and improve the quality forever.

I appreciate your willingness to improve the quality and PRs submission. 
Please suggest what do you think could be introduced more to improve the quality. 
We'll try to make PRs more visible in Open Exchange.

And also the ideas on how to improve the quality of the submissions are very welcome! 

Exactly this "living mechanism" is the core subject of this discussion.

Actually, the OEX team does an excellent job with ongoing verification of the packages.
And I can confirm OEX is not just an archive where you drop your stuff and can forget it.
The outside conditions are on permanent change. Think of releases of the software components,
of changing outside services and references you use.

Most of such changes can be fixed by rather simple Pull Requests on GitHhb.
BUT: This implies that the creator of the package is willing/able to merge it.
- that approach is working in average with acceptable time  [But average is not top qualty]
- though some owners of the repo just are not aware or able or willing to accept.
- and don't even react to personal emails.

This means that such an OEX package is an ORPHAN

I'd like to ask for your opinion on how to handle these orphaned packages!

A few proposals from my side:

  • Simply removing/deleting is no option as this destroys valid knowledge and experience
  • Access or even the whole repo could be passed to some expert in ISC.
    • This sounds comfortable but requires additional resources at ISC sins
    • and an active owner to grant access.  The 2nd isn't always guaranteed.
  • Brute force Adoption / Hijacking / TakeOver using forking in GitHub
    • This sounds hard at first glance.
    • But the community has the chance of a working version versus a broken one
    • And the orphan found a new parent that takes care of it.
    • The visibility of the broken version might be subject to discussion,

I count on your ideas and your feedback.


Discussion (4)3
Log in or sign up to continue

You can see 2 examples of the adoption of orphaned  OEX packages here:

Besides the pure bug fixes, I applied some other enhancements for comfort

  • pointer to the orphaned predecessor
  • fixed Dockerfile to be version-independent
  • fixed pending mapping of SuperServer
  • added support for IPM
  • added installation guide
  • added quality tag
  • added demo server
  • added screenshots
  • enhanced README

Case #1) https://openexchange.intersystems.com/package/JSONExportManyToMany
OEX>>> https://openexchange.intersystems.com/package/JSONExport-ManyToMany-AD
GitHub:  https://github.com/rcemper/JSONExport-ManyToMany-AD

Case #2) https://openexchange.intersystems.com/package/Samples-FHIR-Oximeter-Devices
OEX>>>  https://openexchange.intersystems.com/package/Samples-FHIR-Oximeter-Devices-AD
GitHub:  https://github.com/rcemper/Samples-FHIR-Oximeter-Devices-AD

The packages on OEX are still pending for approval and not public yet.

Hi @Robert Cemper !

Thanks for the initiative! The quality of applications on OEX is one of the key focuses of Open Exchange team.

For both projects I'd invite first the authors to review your PR: @Peter Steiwer and @Zachary Krowiak - could you please take a look?

On the republishing copies of the projects on OEX - I'm not sure that the complete copy with improved readme and fixed dockerfile is a good idea. But the new project that introduces a new quality and new values added to an existing project is something that makes more sense to me. 

Translation from the French community posted by @Lorenzo Scalese 


ISC should keep a copy of the original repo until a new release on OEX (this is eventually the case already)
If a package gets orphaned, it seems to be complicated to hand it over to another member of the community if this copy doesn't exist. 

The account on GitHub could have been closed or the repo could have been deleted. This complicates the situation. We could. of course, try to recover the content from ZPM. But this could be wuite a huge effort of re-engineering. [ If it is available in ZPM at all. -rcc]

Regarding the deletion of the package.
I'm not against the idea, IF there is a valid reason.
It happened to me that I deleted a package because a new functionality of IRIS made it obsolete.
Anyhow, I left the repo on GitHub public in order not to lose the contained knowledge.

In that case, we could decide on an option to "archive" the package 
Not everybody works with the latest version of IRIS. So this might be interesting in some cases.

Thank you & Merci @Lorenzo Scalese