The Question at Hand
When you're preparing digital records for long-term preservation, you face a fundamental choice: build custom tools in-house or adopt an existing solution. This decision isn't just technical; it's about resource allocation. It determines whether your team spends time writing code or managing records.
The release of DART 3 sharpens this focus. DART (Digital Archivist's Resource Tool) is a free, open-source desktop application that packages digital content into BagIt-compliant preservation packages and transfers them to remote storage systems. It now uses a Go rewrite with the Wails framework, adding features like upload-only jobs, support for tarred and gzipped bags, and S3 download capabilities.
For institutions without dedicated engineering staff, DART offers a drag-and-drop interface for creating ISO 14721-compliant Submission Information Packages. For those with development capacity, it includes DART Runner, a command-line tool that can automate the same workflows. The question is whether this ready-made solution serves your program better than custom development.
The Case for Building In-House
Custom tooling gives you control over every aspect of your preservation workflow. If your organization has specific metadata requirements that don't fit standard BagIt profiles, you can design the exact tag structure you need. If you're integrating preservation packaging with proprietary systems, you can build tight coupling that an off-the-shelf tool can't provide.
Development teams argue that building in-house means no dependency on external project maintenance. You're not waiting for someone else to fix bugs or add features. When regulatory requirements change or your storage architecture shifts, you can adapt immediately without filing feature requests or waiting for release cycles.
There's also the expertise argument. Building preservation tools forces your team to understand the underlying standards deeply. You're not just using someone else's implementation of BagIt; you're making deliberate decisions about fixity algorithms, manifest formats, and metadata serialization. That knowledge becomes institutional capacity that persists beyond any single tool.
The Case for Adopting Existing Tools
The counterargument is straightforward: preservation packaging is a solved problem. The BagIt specification exists. The OAIS reference model defines what a Submission Information Package should contain. Writing code to implement these standards doesn't add value unless you have genuinely unique requirements.
Time matters. A team that builds custom tools spends months (or years) on infrastructure that doesn't directly improve their records program. During that development period, digital content sits unpackaged or gets handled through manual, error-prone processes. Tools like DART 3 let you start packaging records today, not after the next sprint planning cycle.
Maintenance is a hidden cost. Custom tools need ongoing support. When staff leave, knowledge walks out the door. When dependencies break or security vulnerabilities emerge, you're responsible for fixes. Open-source projects distribute that maintenance burden across a community. DART's transition from developer Andrew Diamond to Lead Developer Melissa Iori at APTrust shows how open-source stewardship can survive personnel changes.
The batch processing capability in DART addresses a common objection to GUI tools. You can define packaging jobs in a CSV spreadsheet and process many items through the same workflow in a single pass. For institutions with development capacity, DART Runner provides the command-line automation that fits into larger ingest pipelines. You're not choosing between ease of use and automation; you get both.
Where Practitioners Actually Land
Most institutions don't make a binary choice. They adopt existing tools for standard workflows and build custom components where genuine differentiation exists.
A university archive might use DART for packaging faculty papers and departmental records, where BagIt profiles work well, but maintain custom scripts for specialized collections with complex born-digital formats. A corporate records program might package email exports through DART while building proprietary connectors for their SharePoint retention system.
The deciding factor is usually staff capacity. Institutions with dedicated engineering teams can afford to build. Everyone else needs tools that work without writing code. DART's support for S3 and SFTP endpoints means it's not tied to any single repository or vendor. You can point it at whatever storage environment you've chosen, whether that's APTrust, a commercial preservation service, or your own infrastructure.
The community aspect matters more than many practitioners expect. The DART User Group provides a mailing list where institutions share experiences and troubleshoot problems together. When you adopt an open-source tool, you're joining a community of practice, not just downloading software. That collective knowledge becomes a resource your team can draw on.
Our Take
Build custom preservation tools only if you have specific requirements that existing tools genuinely can't meet. The bar should be high. "We want control" isn't a requirement; it's a preference that carries significant cost.
For most records programs, adopting a tool like DART makes more sense than building. You get immediate functionality, community support, and freedom from maintenance burden. The new features in DART 3 address the most common objections: you can upload pre-packaged content, work with multiple bag formats, and automate through command-line tools.
The tradeoff is real. You're accepting someone else's implementation decisions and depending on external project stewardship. But you're also freeing your team to focus on the work that actually differentiates your program: appraisal decisions, metadata design, access policies, and retention schedule alignment.
If you do have engineering capacity, consider contributing to open-source projects rather than building parallel tools. Your improvements benefit the entire community, and community feedback makes your code better. That's how digital preservation infrastructure improves for everyone.
The question isn't whether to build or buy. It's whether your institution's specific needs justify the ongoing cost of custom development. For smaller archives, libraries, and cultural heritage organizations without dedicated technical staff, that answer is almost always no.
