Coordinate an ownership transition plan for legacy ecommerce

[inventhouse]

We hope to work with tCRIL / the community / the Open Source Process WG to transition the OCM/edX Purchase squad away from legacy ecommerce service ownership sooner rather than later. This will, obviously, require some planning and coordination.

The legacy ecommerce service is complicated and brittle yet so critical to OCM/edX that extreme caution and de-risking are required for any change, including OSPRs, dependency updates, and maintainence tasks. This already creates a significant bottleneck which will only get worse as the squad's very limited resources are split between the legacy system and forward development.

On the other hand, if we turn the repos over to a maintainer who has an interest in the legacy system and move edX's deployment off the leading edge, this will dramatically accelerate not only the upkeep, but also the adoption of community-driven features and capabilities.

Some things to figure out:

• How does this transition process work?

  • Timeline?
  • Some sort of call for a new maintainer/owner?

• How do edX's processes need to change to accomodate this transition?

  • Should we fork the repos back into the edX org?
  • How to redirect contributions to the open repos?
  • Any changes needed to deploy from the fork?
  • How to choose what to pull from upstream (if anything)?
  • How to choose what to push upstream?
    • Probably any changes related to Commerce Coordinator integration at least
  • Alternatively: lock the master branch to edX users and create a new default branch, main, for community development

[feanil]

While 2U is still using eCommerce in production, how will maintenance be handled? eg. Given the criticality of the service in the revenue flow of edx.org, I assume there will still be effort from 2U to keep the service up-to-date and have the latest security patches be applied to any libraries used in the service.

At what point in the evolution of commerce-coordinator capabilities would 2U stop want to stop supporting the maintenance of the ecommerce service? This can probably inform a timeline for any transition that we might want to do.

[inventhouse]

Sorry for the delay, there's still a lot of transition/merger stuff going on.

The squad will, obviously, need to do maintenance and security updates that are directly critical to 2U's use of the legacy service, but anything else will become even harder to prioritize than it has already been. We raised this now because we do not want to do the community a disservice by deplaying a transition when the bottleneck is getting more constrained, but, of course, we wouldn't want to create the opposite problem either.

We're working on an approach document for community stakeholders and hope to get that out by the end of next week; again, I apologize for how long it's taking to get this engagement off-the-ground.

[feanil]

@inventhouse no worries, I understand that the 2U IT transition has not gone smoothly for some things.

Given your thoughts on maintenance and what you initially posted, here are the things that seem to be at play from my perspective:

1. 2Us wants to deprecate ecommerce internally. The cost of maintaining it and building new features on it is too high for edX/2U
2. There is not a lot of excitement for having the ecommerce replacement be a large open source project that serves all possible use-cases for the community.
   • The risk of taking community contributions that result in breakage for edx.org is too high and so it would be hard to maintain a vibrant community in this space.
   • 2U wants to move more towards off the shelf commerce services where possible.
3. It feels like there is an assumption that the rest of the community would not want to deprecate ecommerce and replace it with something else?
   • Or relatedly that the community would want 2U to build whatever that something else is for them?

The last assumption and its sub-assumption are what I came up with as explanations for why forking ecommerce would look like a good option. It would allow for a clean separation if those two assumptions are true.

Note: I'm not confident that the last two assumptions are true but I'm looking for understanding so those are some of the ways I'm seeing this from the outside.

I'm also not sure of why we can't start the deprecation process ecommerce as defined in the DEPR OEP. One of the steps in the process is to see if anyone else in the community wants to maintain it. Even if they do, we can come up with a transition plan that I think could meet 2Us needs until they have transitioned away from ecommerce. If they don't then we save ourselves a lot of work all-around.

[inventhouse]

One of the steps in the process is to see if anyone else in the community wants to maintain it. Even if they do, we can come up with a transition plan that I think could meet 2Us needs until they have transitioned away from ecommerce. If they don't then we save ourselves a lot of work all-around.

I think this sounds right; my original thinking when I wrote this ticket is that we want a good plan and that we were willing to "get out of the way" (but we'd rather just build forward and save the work, as you said)

[inventhouse]

We have officially deprecated the ecommerce and ecommerce-worker repositories; at this point we do not expect to be transitioning ownership, and plan to move them to unsupported after they are replaced. Closing this ticket.