DTC 07-09-2024

[belsrc]

What's the path to open source?

• From a code perspective we need to figure out:

  • Governance (mentioned below) and licensing (below).
  • What exactly we want to OOS. Some "first to come to mind" would be things like the Deck.gl fiber. The ArrowLayers. The design system. These can all be used in various HG apps and would provide value to the "outside" world.
  • How do we want to structure it? Likely monorepo as opposed to traditional repos. Makes it easier to get full picture and keep things in sync.
  • The most common MIT, Apache, BSD and GPL. There are also more niche and one off licenses as well.

• Work side.

  • Refactoring to make various things more agnostic.
  • Setting up CI pipeline (Github Actions) to automate as much as possible.
  • Setting up bots to handle as much as possible in the issues/pr's area.
  • Making sure that dev tools cover all areas that we want them to cover.
  • Provide a thousand foot overview for the base README (if we go the below heavy documentation route) as well as other DX docs like issue templates, contrib.mds and the like.
  • https://opensource.org/licenses?categories=popular-strong-community
  • https://opensource.org/license/apache-2-0

  Apache license specifically addresses the grant of rights from project contributors and it expressly addresses the fact that modern companies are typically made up for more than one legal entity (for example, a parent company and its subsidiaries). Most open source licenses don’t address these points.

Note

Largely covered in other topics below. The license issue is really up to the lawyers. Waiting for guidance. Apache seems to be the most well known go-to. But there is also the possibility of rolling one from scratch.

Governance

• See the PDF [[✓ OSS Governance Models]] that I put together, but this would likely be some sort of Self-appointed Council + Corporate Backed governance model.

Note

Corporate-backed + council. Corporate-backed would also let us implement a CLA

• Google
• Meta

Strategic communications w/ customers and with public about the open source effort

• This one is a bit outside of the development team. For the company as a whole this would be more on Marketing department.
• Things that the development side could do to raise visibility and attempt to be leaders in the space:
  • Pipeline generated documentation. Preferably something that can also have more than just API documentation. Also, should have the ability to have live component demos.
  • An HG developer blog would be a nice form of public facing marketing. Though that is another whole set of "how do we"s.
  • Some examples:
    • Uber Engineering Blog
    • Etsy Code as Craft
    • Engineering at Meta
    • Builder.io Blog

Note

Customer communication is still primarily up to leadership. See below Documentation about public facing communication possibly being rolled into documentation site.

Is Dev TK a shared project or dedicated project? (is this a dev lead + dedicated dev team or do we have ICs just manage who is contributing to it)

• It sounds like the current game plan is to move some people around and more or less dissolve Core. At which point, we would make up the base of the council. At the start, it will be a lot of work (full time) so that would be our "primary" focus. Later on, once it is established, there would probably be room to take in contributions from other devs. Don't see it being shared at the start. There is too much that needs to be done in the way of setup for that to be reasonable.

Note

In agreement with the above. Will likely be a three person council at the start.

Succession (new dev lead or transition?)

• Mentioned above.

Scoping and architecture related to modules

• This would probably be a larger discussion with those on the "council" (below). We would need to determine what all needs to get moved, aiming towards an agnostic approach and what all that means for current projects.

Note

Assortment of agnostic utility functions (domain split; @hg/math, @hg/geo, etc). Fiber render and arrow layers. With the fiber stuff being a place to battle test it and further develop it before being reintroduced (PR) to the deck.gl community repo.

Documentation so anybody knows how to use Dev Toolkit

• This can go many different ways. We currently have automated, code-base API documentation via typedoc. These can be used to generate a documentation site (i.e. https://arrow.apache.org/docs/js/). But this can also be used to just generate Markdown files (what we do currently) which we can use if a larger documentation site. Ideally, for things like the Design System we would also have interactive examples. Like https://react-spectrum.adobe.com/react-aria/Button.html or similar. But there is an almost infinite number of documentation frameworks. We could also tie in some of the things mentioned in the above marketing heading into the doc site if that is something that we wanted to do.

Note

It seems like people don't know where to find things or that they even exist. So things would need to be easily searched and discoverability. Would need a good template system. Could use something like docusaurus or fumadocs(additional option: vocs. Need to have a published version of the DS stories. This would likely be a separate domain. Though a case could be made to embed them into the standard docs for better visibility. Pros and cons to both. The mentioned frameworks should allow us to use the generated API docs (hand jamming them is not really an option). It would also allow us to add long form documentation as to why we made certain decisions and what was all tried before settling on the current route. Would prevent new hires from reintroducing old and/or bad patterns. Then this could also be used for onboarding. Additionally, would be nice to incorporate mini REPL's into the function docs (like lodash's docs) in order to actively use/test the functions.

Additional Idea: Training

As an open source project, we might want to make some features / branches of DevTK for new devs to experiment with. I.e., they learn projects via playing with DevTK, creating new modules building out from DevTK, etc. That way they can start with useful contribution from the moment they are hired instead of 30 days later.

• This is a massive rabbit hole that we could go down.
  • We could make a secondary repo (private to HG) that is just for onboarding. The new employee could branch off and do some task and then push up. Then we could review and provide points and what not. Would need to be kind of like the sandbox page.
  • There is also the route of using something like Stackblitz/Codesandbox.
  • Among many other avenues that I'm not thinking of right off the bat.

Note

If projects were setup in a supported manner and consumed the packages then that would be a good, maintained test bed. Contributions to the DTK is also a possibility. Would give the insight in how we work, what we work on, our standards, etc.

If we did a sandbox it would be an extremely stripped version where it would be truly a sandbox with just the dependencies included.