The end of xRM Portals Community Edition

As 2020 comes to an end, so does xRM Portals Community Edition. On December 19th, 2020, I marked the GitHub project as archived, so that everything would become read-only, including the code, wiki, and issue management features.

I was a little hesitant to take this step because of my personal connection to the code, my career, and all the unsung developers that worked tirelessly to build it from its inception at Adxstudio all the way until its acquisition and one-time release by Microsoft. Nostalgia aside, I feel it was the right time, given the ever-increasing inactivity on the project and my judgement of it having accomplished the project’s goal of providing a migration path to Microsoft’s online portals service.

What follows is my retrospective of the project.

The project was initiated on August 25, 2017, giving it a lifetime of 3 years and 4 months. While I can’t recall us having a pre-planned duration for the project, I think this duration is about as long as we would have envisioned if we’d tried to.

The main objective for the project was:

…to provide a way of upgrading from Adxstudio Portals 7 to this supported version of portals, and that provides a migration path to Microsoft’s hosted offering of Portal Capabilities for Microsoft Dynamics 365.

…Using Microsoft’s online version should be the primary goal of existing and new users, and using this version is primarily intended for those with special circumstances where they need to stay on premise for a longer time period while preparing to move online.

https://github.com/Adoxio/xRM-Portals-Community-Edition#objectives

I think 3+ years was a sufficient amount of time for those seriously intending to move online to perform that task. For those who haven’t yet, the source code is still available if needing to make any additional changes for their particular needs.

As an open source project, some interesting statistics are:

  • There were 72 commits, covering bug fixes, addressing compatibility issues, and general maintenance efforts.
  • There were 105 issues, of which 76 were closed and 29 remained open. The issues were a mix of bug reports and general questions.
  • There were 20 pull requests, of which 18 were closed and 2 remained open.
  • There were 7 contributors. This may not be a lot of people or as many as I’d hoped for, but I don’t think it’s unexpected as it confirms what I’ve anecdotally seen from other open source projects that most users who submit issues don’t participate in contributing.
  • There were 50 forks. It’s hard to draw any conclusions from this but when looking through the forks it’s interesting to see the changes some people made in their forks.
  • There were 99 stargazers. I would have loved to have hit the 100 mark, but 99 will have to do!
  • There were 48 watchers. This is perhaps a better gauge of who took an active interest in the project than stargazers since watchers can receive notifications for issues.
  • We created 10 wiki pages. The documentation from Microsoft had a few gaps and the wiki served as a good place to add supplementary content.

When the project was started, there were some obvious gaps in online portals for adding custom code that may have made it hard for users to switch to online. New features have since filled this gap and give alternate approaches to introduce custom code in ways that allow custom experiences that previously would have required changes to the portals code base itself.

  • The portal web API allows CRUD operations to be performed using client-side code, and with modern single page application (SPA) frameworks such as React, the user experience can be very sophisticated.
  • The OAuth 2.0 implicit grant flow allows for companion web apps to be implemented so that custom server-side code can be written, enabling complex business logic which shouldn’t be exposed to end-users.

One limiting factor to addressing issues was the omission of the unmanaged solutions from the initial open source one-time release. Several bugs couldn’t be fixed because the issues were contained within the managed components of the solutions (i.e. workflows, plugins, schema/customizations).

Part of the project scope was to limit changes to those that would remain compatible with the online version of portals. This meant some changes from pull requests couldn’t be merged. It was always enticing though to implement new features and venture down a different path than online portals goes. If Microsoft were to ever release the unmanaged solutions, or someone were to undertake the effort to reimplement the solutions, one could conceivably take the source code in any imaginable direction.

If you used the project, I hope it helped you. If you have any parting words for the project you’d like the rest of the world to see, please share them in the comments.

Good-bye xRM Portals Community Edition, it was fun while it lasted!

Leave a comment