ABCs of triple scripts

There are a set of conventions in the world of triple scripts intended to make it more attractive to prospective collaborators to work on projects that adopt triple scripts for project metatooling than compared to projects that rely on other "traditional" build systems and other workflows.

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, say, .NET, for example, you might declare to downstream participants that you and any other project maintainers are using a certain set of tools for a certain version of the framework, and you expect that downstream participants will go learn about getting and working with those things. 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 such as Git, then copies of the aforementioned tools are checked in to version control, too, so that any collaborator has the tools they need to get the project built and working simply by virtue of having cloned the repository.

It is optional but encouraged in the world of triple scripts 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:

1. Acquire – fetch all external dependencies that are not shipped directly in the project's own source tree, if any
2. Build – produce an executable program (i.e. the form that is capable of doing useful work)
3. Customize and contribute/collaborate – 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.