On Open Source
---
Research checked: 20 September 2026.
“Open” can describe very different AI releases. One project publishes code; another provides downloadable weights; another also releases training data, preprocessing tools, evaluation code, and intermediate checkpoints. These choices enable different kinds of work. A useful discussion of openness begins by identifying the available artifacts and the permissions attached to them.
Source: screenshot from the Open Source Initiative’s Open Source AI Definition 1.0.
The Open Source Initiative’s AI definition centers on freedoms to use, study, modify, and share a system. Its preferred form for modification includes parameters, the relevant code, and sufficiently detailed training-data information. The definition does not simply require every raw training example to be publicly downloadable; it specifies what information and access should be available, including descriptions of unshareable data. These details matter when evaluating a release against that particular standard. OSI, Open Source AI Definition 1.0.
Downloadable weights are valuable even when other parts of the development process remain unavailable. They can enable local inference and, where the license permits, adaptation. But weights alone do not reveal exactly how a dataset was filtered or let a researcher rerun the original training recipe. In this article, “open weights” describes that narrower availability without assuming that the full system meets an open-source definition.
OLMo offers a concrete example of a release designed for scientific study. Its authors published model artifacts together with training data and training and evaluation code. This broadens the questions researchers can investigate: they can examine not just final outputs but also parts of the process that produced the model. Groeneveld et al., OLMo: Accelerating the Science of Language Models.
Dolma similarly treats the training corpus as a research object. The project describes an open pretraining dataset and the tools and processes used to build it. This makes data composition, filtering, and related decisions more available for inspection and experimentation. Access to such materials improves the possibility of reproducible research, although reproducing a large training run still requires substantial resources. Soldaini et al., Dolma.
My practical assessment would separate scientific access from deployment convenience. A team may be able to run a model locally yet lack the infrastructure to train it again. Another team may have the compute but insufficient information about the original data pipeline. Both can benefit from openness, but the benefits are different and should not be collapsed into a single label.
There are also operational responsibilities. Hosting weights yourself means owning version management, monitoring, updates, and the application’s behavior. An available training recipe does not automatically make outputs accurate or the system secure. Conversely, an API may be convenient while giving users little ability to inspect changes behind it. These are engineering tradeoffs to evaluate for the intended use.
Before relying on an “open” claim, I would inventory weights, architecture, inference code, training code, data information, evaluations, and the actual license terms for each. Check the exact release rather than assuming all versions share the same conditions. The strongest contribution of open development is that it gives more people concrete opportunities to inspect, test, reproduce, and improve the work.