Arch Lunch with Braden MacDonald, CTO of OpenCraft - 2019-10-17

He/you is Braden.  They is OpenCraft.  We are edX.  (unless otherwise clarified)
Things he's surprised the platform doesn't support:
  • In-video quizzes
  • Easier authoring in studio


OpenCraft's onboarding handbook: https://handbook.opencraft.com


Building in time to their workflow to account for friction around merging upstream changes.


Do they wait for things to get merged before using them?
  • Some clients are chill and can wait
  • Often will have to deploy to a fork temporarily


What directions would you like to see the platform go?
  • Excited for plugins
    • Would like to be able to build custom stuff as plugins, which isn't always possible today
  • Deployment is super complex
  • Blockstore
  • APIs - documentation


Repositories they've contributed to?
  • platform and blockstore?  Or others?
  • used to do work on analytics
  • haven't touched many of the others
  • payment providers


Challenging contributions?
  • analytics devstack - there was no way to run it locally
  • First version of content libraries


OpenCraft uses Docker devstack


Sometimes have different devstacks if:
  • extra IDAs
  • Client is a release behind


How often clients on older versions?
  • Clients who have been with them for a while, always on named release
  • Never more than one release behind, generally
  • If came from another open edx provider, maybe more behind, but they work with them to get their forks up to speed


Tutor?
  • Has not tried himself
  • worried about fragmentation and having too many ways to deploy platform
  • Argument for doing things at two different scales - not everything edx.org needs is going to apply to smaller scale deployments


Excited about Appsembler's Figures package
  • community supported analytics packages for smaller instances, then that's good


Changes to platform he has viewed as big steps forward or backwards?
  • Quite a few!  But not many that strike him as steps backwards.
  • Simplifying configuration was exciting
  • Documenting APIs
  • Doesn't like: code in thousands of repositories - dependency management is hard.  Doesn't view as a step forward.
  • Likes the move to APIs with frontends that consume them - another big step forward


What can we do to expedite API improvements?
  • edX spends a lot of time on upgrade efforts


How can the community help expedite these arch improvements (i.e., the APIs)?
  • Hard for community to document an API if they don't have institutional knowledge of how it's supposed to work
  • As part of existing projects, wherever working already, do housekeeping.
    • how do you have that conversation with your business clients?
      • Depends on how involved clients are, frankly
      • Communicate clearly
      • If more hands off, just do what they need to do


AJ mentions talk that OpenCraft gave this year at conference:
  • history of OpenCraft involvement


Questions for edX:
  • What are we (edX) excited for?
    • API documentation, hope is part of larger effort tot have a well documebnted set of more generalized APIs that are useful for the community and us
    • DevOps config and deployment work
      • Bunch of cleanups in Juniper
    • Python 3
    • Adding APIs to XBlocks
      • Has that effort grown?  Is this an approach we can take to other XBlocks?
        • Has not gone anywhere really
        • Has ideas for replacement/evolution of XBlocks which support offline mobile from the get-go.
        • OC built support for sandboxed XBlocks
          • in an iframe on a different origin
          • can execute JS but can't access session data



What are good ways we can ask the community for help? (ref: python 3)
  • Usually not looking for something to do on its own, looking for something tied to their projects
    • Have the INCR project really well defined - that's very helpful
  • When you ask us to try new things out before their finished, that's helpful (especially ops-related things)  Happy to try out early versions.


We have engineers who are not as open source-centric, and we also hire junior engineers.  What would you tell them is the value of being open source first?  Making that an essential part of their engineering lives?
  • On individual level: Benefit is that your work is public and people can see what you've done, and you can point to it.  Pragmatic reason.
  • Philosophical reason: we're all benefiting from open source constantly, seems good to give something back and not just take, take, take.
  • Benefits from open source - a lot more code review.  More likely to be higher quality.
  • Engaging with community, has its ups and downs, but is rewarding.
  • Often a business challenge to get people to do open source - developers like it
  • Hard to prioritize against other things demanding their attention


Evolution of XBlocks
  • edX has been talking about frontend plugins - could this evolve into what Xblocks could be?
  • Interested in frontend plugins - technically challenging
    • Should connect on how this is related to XBlocks going forward


Thoughts about replacing/evolving XBlocks?
  • Idea: Doing more in JS.  It runs everywhere.  V8 in python, JS runtime in iOS, very easy to get it wherever ou want.
    • Can't do offline in python.  But in JS, its trivial.
    • putting allt the logic for a courseware component in JS, including the server side part of it.
      • Gives you a ton of flexibility
  • How to do assessment XBlocks so you can't cheat - i.e., when you need a backend.


Awkward question from Ned:
  • What would you tell edX management to convince them it's important to accept/invest in contributions?
    • The general argument is that you get features built for free / bug fixes for free
    • hopes data shows that this is a worthwhile investment (i.e., more value from contributions than time spent reviewing it)


What happens if a OSPR isn't accepted by edX?  

  • they'll find some other way to implement - usually there's a good reason. 
  • Will try to do as a plugin if a client insists to do it

 What's the average/ideal lead time to get something merged upstream?

  • Ideally a couple weeks so it coincides with sprint goals

Harder to get product buy-in or engineering buy-in?

  • Usually product is harder.
  • Engineering buy-in early isn't has hard.