Problem
Open source is often described as a software distribution model. That is accurate but incomplete. Open source also determines who can learn from code, adapt tools, preserve software, audit systems, build creative environments and sustain technical communities.
The problem is that cultural discussions of software often focus on finished products while ignoring the shared infrastructure below them. Creative coding libraries, browser standards, build tools, audio frameworks, fonts, package managers and documentation systems shape what artists and researchers can attempt.
Electronic Artefacts needs to discuss open source as cultural infrastructure: a material layer that supports creative practice, knowledge publishing and long-term access.
Introduction
Open source means more than public source code. The Open Source Definition describes distribution terms that permit redistribution, access to source code, derived works and non-discrimination. Those legal conditions matter because they allow communities to study, modify and circulate software.
But the cultural value of open source depends on more than licensing. A project can be legally open and practically unusable. Documentation, maintainership, governance, examples, tests and community norms decide whether code becomes infrastructure.
Context
Creative technology depends heavily on open source. Processing, p5.js, WebGL tooling, audio libraries, visualization frameworks and static site systems all extend what individual creators can build. They also create dependency chains. A small library may become part of thousands of artworks, websites or research tools.
Open source therefore belongs in a Knowledge Hub about art, software and research. It is not a side topic. It explains how technical cultures reproduce themselves.
History
The history of open source includes free software, academic code sharing, Unix culture, hacker ethics, internet collaboration, community governance and institutional adoption. The term “open source” helped clarify licensing and business compatibility, while free software retained a stronger ethical vocabulary around user freedoms.
For creative coding, open source made programming environments teachable. Learners could inspect examples, copy sketches, change parameters and share modifications. That pedagogical loop helped computation become a creative medium.
Core concepts
License: the legal terms that permit or restrict use.
Source code: the preferred form for understanding and modifying software.
Fork: a divergent development path from an existing codebase.
Maintainer: a person or group responsible for review, releases and stewardship.
Dependency: a software component used by another project.
Commons: shared resources governed for collective use.
Architecture
Open source infrastructure has layers. The legal layer defines rights. The technical layer includes repositories, issues, builds, tests and releases. The social layer includes maintainers, contributors, norms and governance. The documentation layer teaches use and preserves context. The archival layer keeps code, releases and dependencies recoverable.
When any layer fails, the project weakens. A library with permissive licensing but no documentation may be inaccessible to new users. A popular tool with exhausted maintainers may become fragile infrastructure.
Implementation
For Electronic Artefacts, open source should be documented with precision. If a project uses an open-source library, the article should name the library, role, license when relevant and preservation implication. If a tool is inspired by open-source practice, the article should separate inspiration from actual license status.
Internal tools can also adopt open-source habits without being public immediately: clear README files, versioning, changelogs, examples, issue notes and dependency records.
Practical applications
Open source supports education because learners can inspect working systems.
It supports preservation because code can be archived, rebuilt and studied.
It supports creative practice because artists can adapt tools instead of waiting for closed vendors.
It supports knowledge systems because schemas, validators and generators can be reviewed and extended.
Tools
Useful tools include Git, public repositories, package managers, issue trackers, changelogs, semantic versioning, license files, dependency scanners, documentation generators and static site builds.
Evidence
The Electronic Artefacts Knowledge Hub itself benefits from open technical patterns: structured Markdown, generated pages, JSON-LD, graph validation and static output. Even when a repository is project-specific, the culture of inspectable systems shapes the work.
Creative coding also provides public evidence. Processing and p5.js show how open tools can create learning communities around code, art and education.
Editorial method
A good open-source article should distinguish license, governance and cultural effect. It should not call something open source simply because it is visible online. It should ask who can use it, who can modify it, who maintains it and what happens if dependencies disappear.
Common mistakes
The first mistake is equating public code with open source.
The second mistake is romanticizing unpaid maintenance. Infrastructure has labor costs.
The third mistake is ignoring licenses until publication. Rights should be documented early.
Electronic Artefacts implications
Electronic Artefacts can treat open source as part of its intellectual environment. VASTE, ORETH and future tools should document dependencies and reusable patterns where appropriate.
The Knowledge Hub can also publish educational articles that help readers understand not only what a tool does, but what cultural conditions made it possible.
Knowledge graph role
Open source becomes more legible when it is represented relationally. A tool can depend on a library. A project can use a technology. A publication can document a concept. A program can be maintained by an organization. These relations make infrastructure visible.
For Electronic Artefacts, that matters because software dependencies are not only build details. They are part of the cultural and technical conditions of the work. If a future project uses Web Audio, WebGL, p5.js or a graph library, the Knowledge Hub should be able to explain the relation between the project, the tool and the broader open-source ecosystem.
Evaluation criteria
An open-source record should answer more than “is the code public?” It should ask whether the license permits use and modification, whether the source is the preferred form for change, whether releases are identifiable, whether maintainers are visible, whether documentation exists and whether dependencies can be preserved.
Creative projects should also ask what kind of learning the software enables. A library that is readable and well documented can become pedagogy. A library that is powerful but opaque may still be useful, but it plays a different cultural role.
Preservation angle
Open source helps preservation only when the code and its context survive. A repository without releases, examples, licenses or dependency records may be hard to reconstruct. A responsible cultural archive should therefore preserve not only source code, but also documentation, version constraints, sample inputs, outputs and build instructions.
Reader pathway
A search visitor may arrive through a practical query about open source, creative coding or software culture. The article should move that reader from licensing into infrastructure: who maintains the code, what depends on it, how it teaches, and how it can be preserved. From there, the natural path leads to Creative Coding, Digital Preservation and future software archive records.
Future work
Future entries should cover software preservation, creative coding libraries, dependency archives, licenses for cultural projects, maintainership models and open-source governance.
Related concepts
Read Open Source, Creative Coding, Internet Culture and Digital Preservation.
Suggested reading
Start with the Open Source Definition, then study concrete creative tools such as Processing and p5.js through examples and repository histories.
Related articles
Continue with Creative Coding Pedagogy from Logo to p5.js and Digital Preservation and Living Archives.
Glossary
Open source: software distributed under terms that allow use, study, modification and redistribution.
Maintainer: steward of a project repository and release process.
Fork: a separate development path derived from an existing codebase.
Dependency: software required by another system.
Limitations
Open source does not solve every problem. It can reproduce inequality, burn out maintainers and create fragile dependency chains.
It also does not replace editorial judgment. A public knowledge system should document open-source use without turning every article into a software advocacy text.
References
- Open Source Initiative. The Open Source Definition.
- Processing Foundation. p5.js.
- Electronic Artefacts. Creative Coding and Digital Preservation records.