When a project adopts triple scripts for its metatooling, there are a set of conventions that make it more attractive to prospective collaborators than projects that rely on other more "traditional" build systems:
First, if it doesn't ship in a single source tree all the dependencies needed to do a full build, the project offers a tool that is straightforward to use that will fetch all externally provided dependencies in a single shot. Whether intended by the authors of the third-party code or not, the collection of all external dependencies can be considered the "SDK" that the program targets, and it is this SDK which is needed to do a full build. Other projects, on the other hand, provide all dependencies within the single source tree. By closely following this pattern, projects which adopt triple scripts are already able to eliminate much of what comprises implicit step zero unfortunately inherent to most traditional software development.
Second, the tools used for building the project are embedded directly within the project source tree itself. In traditional workflows, if your program targets .NET, for example, you might instruct downstream participants that you and any other project maintainers use a certain set of tools for a certain version of the framework, and expect that downstream participants will go learn about getting and working with these tools and frameworks. This is the part of implicit step zero that sometimes goes by the description "setting up a development environment". In the traditional workflow, the project may or may not explicitly include documentation for getting past this hurdle of development, and what documentation does exist may or may not be up-to-date and sufficient.
In the triple scripts ecosystem, we know that any potential collaborator is able to pass this hurdle because the acquisition and build tools are included along with the source code. If the project uses a source code management system (like e.g. Git), then copies of these tools are checked in to version control, too, so that cloning the repository means that any collaborator already has the tools they need to get the project built and working.
It is optional but encouraged that projects include any other tool that guides collaborators towards the most effective means of the contribution process (e.g. preparing patches, submitting them for review, et cetera).
These could be called the ABCs of triple scripts:
- Acquire – fetch all external dependencies that are not shipped directly in the project's own source tree, if any
- Build – produce an executable program (i.e. the form that is capable of doing useful work)
- Customize, collaborate, and contribute – make meaningful changes to the program and provide those changes to the wider community
It is recommended the projects follow these ABCs and actually ship these tools as Acquire.app.htm, Build.app.htm, and Collaborate.app.htm (where Build.app.htm is the only constant that is expected to be included in any given project, since some projects will not require third-party dependencies and others will not have a complex or even a well-defined contribution process).
Furthermore, for projects which are implemented as triple scripts themselves, the intended experience for those hoping to contribute is to be able to take advantage of the property of SDIPD (aka "non-destructive compilation") and make meaningful changes to the program by starting with the triple script "executable" itself as the basis for development. Although this doesn't preclude anyone opting for a more "traditional" workflow that involves cloning the project repository and building from source, note that this MUST come at the discretion of the user—any program for which the "executable" cannot serve as an equivalent to having the source repository that produced it is not a triple script.