Scratch-gui: Question: Why is Scratch 3 spread across multiple repositories?

Created on 29 Aug 2017  路  1Comment  路  Source: LLK/scratch-gui

^^ i.e. scratch-gui, scratch-blocks, scratch-vm, scratch-render... Why spread it like that?

question

Most helpful comment

Good question! With Scratch 3.0 we split things up into multiple repositories for a number of reasons:

  • In the future we envision building Scratch "microworlds" (PDF) that are focused on a singular type of media. For example, we have imagined building a "Music Microworld" that doesn't have a stage but instead focused solely on sound and music or a "LEGO Microworld" that doesn't have a stage or audio engine but instead focuses on Scratch programming with LEGO robotics kits. Because of this it is most helpful for us to think about the Scratch technical infrastructure as a kit of parts that can be assembled in many different ways rather than just the Scratch editor that we will be releasing with 3.0.
  • With a large team of people working on a project as big as Scratch it can be helpful to have some separation between major technical components. This generally improves workflow, testing, collaboration, and maintenance by thinking of a large software system as discrete components that have clearly defined APIs. This software engineering concept sometimes refereed to as "Separation of Concerns". This is something that was not done in prior versions of Scratch and has contributed to difficulties of maintenance and collaboration.
  • As Scratch moves onto mobile devices and beyond it is important that each piece of Scratch be able to be replaced and/or rewritten without the team (or community!) needing to rewrite the whole thing from (no pun intended) scratch. Splitting functional areas out into components reduces this risk.

>All comments

Good question! With Scratch 3.0 we split things up into multiple repositories for a number of reasons:

  • In the future we envision building Scratch "microworlds" (PDF) that are focused on a singular type of media. For example, we have imagined building a "Music Microworld" that doesn't have a stage but instead focused solely on sound and music or a "LEGO Microworld" that doesn't have a stage or audio engine but instead focuses on Scratch programming with LEGO robotics kits. Because of this it is most helpful for us to think about the Scratch technical infrastructure as a kit of parts that can be assembled in many different ways rather than just the Scratch editor that we will be releasing with 3.0.
  • With a large team of people working on a project as big as Scratch it can be helpful to have some separation between major technical components. This generally improves workflow, testing, collaboration, and maintenance by thinking of a large software system as discrete components that have clearly defined APIs. This software engineering concept sometimes refereed to as "Separation of Concerns". This is something that was not done in prior versions of Scratch and has contributed to difficulties of maintenance and collaboration.
  • As Scratch moves onto mobile devices and beyond it is important that each piece of Scratch be able to be replaced and/or rewritten without the team (or community!) needing to rewrite the whole thing from (no pun intended) scratch. Splitting functional areas out into components reduces this risk.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

rschamp picture rschamp  路  3Comments

thisandagain picture thisandagain  路  3Comments

ericrosenbaum picture ericrosenbaum  路  3Comments

ericrosenbaum picture ericrosenbaum  路  4Comments

thisandagain picture thisandagain  路  3Comments