INPUT NEEDED: Fork Research

Hello all,

In an effort to better understand where time invested in platform pluggability would be most valuable, we’d like to hear about your forks :slight_smile:

We’d like to hear about both forks to support changes in backend services and frontends.

If you are deploying the platform from a fork, we’d like to know:

  1. In a few sentences, what is your forking strategy, what is the purpose of your forks?
  2. Which repositories have you forked? Please link to your forks if possible.
  3. Broadly speaking, what categories of things have you changed in your fork? For example, did you
    a. make branding changes
    b. make UX changes
    c. add fields to models and/or screens – which ones?
    d. add new features
    e. remove features
    f. fix bugs
    g. something else
  4. When did you create your fork?
  5. How often do you pull in changes from upstream?
  6. How much effort is it for you to pull in changes from upstream to your fork?

Have you used platform plugins? If you have, were there problems you couldn’t solve that required you to maintain a fork?

Thanks in advance for sharing. This information will hopefully help us formulate the best plan to reduce your burden managing forks. Ideally, over time, we can eliminate the need entirely.

7 Likes

I wanted to acknowledge and add some great input from @chintan in a Slack thread.

Capturing the details here for the benefit of having a consolidated, long-lived conversation.

  • Adding extra fields in registration form and changing look and feel for the fields along with custom behavior of them (say dropdown or checkboxes etc), for that I need to change the frontend-authn repo
  • Adding custom fields in courseware, so those fields needs to be shown in settings or advanced settings page, for that another repo
  • Adding extra fields and changing look and feel of profile pages, so another repo for that
  • Changing look and feel for accounts page so extra repo for that
  • Changing things and behavior in courseware or learning mfe, and I’d usually deny those changes, but if someone insists that too is extra repo
  • Dashboard look and feel, for example they don’t want the course box the way it looks and wants in different format, maybe a list, maybe long box etc so those changes
  • Usual whitelisting through header and footers
  • New static pages, so in this case either I can add them to edx-platform mako code, or add another mfe, if I add them to mako code, header and footer aren’t consistent to react pages, and if I add it to MFE it’s another repo.
3 Likes

Hello! :sparkles:

Talking about forks, the first thought that came to my mind was the edx-platform. In edunext we have edunext-platform, which is not a direct GitHub fork, but the branches are based on edx-platform. The main purpose of this is to add features or fix bugs related to the multitenant case or to solve needs from our clients, for example, having third-party auth separated by site, restricting token access by site, allowing instructors to manage certificates, or allowing creating a course mode through studio. However, we only have these custom changes for our SaaS instance, and we were making a significant effort to avoid adding modifications directly to the fork contributing to the community by opening upstream PRs (if we think it will be helpful in the community), moving the changes to Django apps as eox-tenant or eox-core, and using hooks (events and filters).

The strategy with edunext-platform is that when we want to migrate our SaaS, we create a branch with the release name based on the release branch from the edx-platform; we try to avoid direct changes, but if we can’t or don’t know how to do it, we apply the change directly to the branch, and if the community added fixes, we backport it.

Another situation in which we used a fork was when we wanted to use a dev branch (repo: paragon, branch: alpha) because it worked for us, and we wanted to add some things. We used a fork to avoid waiting to have that branch merged.

I think the other forks are used to contribute to the community; that’s the information I have about forks.

1 Like

We have to fork repos for these major reasons:

Multi-tenancy: For our SaaS offering, we must fork edx-platform and other service repos to incorporate custom features on top of what is available off the shelf. For example, branding, analytics, and user management on a per-tenant basis.

Custom Features: For our enterprise customers, we fork repos to integrate custom features since there is no way of implementing those features as plugins. For instance, Edx platform plugins have limited support for passing additional context to mako templates. Additionally, other services like course discovery and ecommerce lack a plugin framework, requiring us to fork their repos to add custom features. In the case of MFEs, for a small branding change or small change header and footer forking is necessary.

We pull changes from upstream when:

  • There is a need to upgrade to a named release.
  • A critical security fix becomes available.
  • A much-awaited feature is present in the upstream.

The effort to pull changes from upstreams or upgrade to a named release depends on how many customizations we have in our fork and how those customizations are made. This effort can range from 2 to 32 man-weeks.

@Zia.Fazal: Note that this doc is for adding the plugin framework to other IDAs. It really shouldn’t take much effort, but is sitting until someone needs this capability (for other IDAs), and it sounds like you could use it.

2 Likes

Typically in most of our client projects, we would have to fork MFEs mainly their header/footer/brand, this is usually because of UX/UI changes requested by the client.

edx-platform is rarely forked, and we do typically create a Django plugin to add or extend a featuer depending on the client request.

Some client’s would indeed request a feature that might could be implement to upstream, and as to why we probably wouldn’t have that feature upstream, is because of multiple reason:

  • The feature might only be needed for the client’ unique use case
  • Time : the client’ might not apporve the time needed for it to be upstream, because then it would take a much longer time process, for PR reviews, tests, ensuring the featuer works on different cases.
  • The client might be running an older version, thus for us to have it upstream, it means that client would need to bare the cost of 1) the cost of upgrading to latest release + 2) cost of developing the feature + 3) cost of having that feature landed upstream.

In regard of fixing bugs, we typically open them upstream, it’s win win situatoin. The only caveate I can add here that it might be trickey if the bug is resolved for an older relase of the platform. But for example I am currently working on this fix: course certficate status after requesting by ghassanmas · Pull Request #1348 · openedx/frontend-app-learning · GitHub which an issue reported by a client.

We pull the changes from upstream when a client’s has forks and we are doing an upgrade for their platform. How hard/time consuming this would depend on 1) how heavy are the changes fork + 2) delta of changes between upstream the current client’ target version. e.g. the delta would > if client is upgrading 5 releases or if it’s of a compoenent with high development

1 Like