Your Question, Redefined
My main concern is people dropping out and leaving half finished work behind but I'm sure there are other challenges I need to consider.
There are many such challenges with any drop-in/drop-out resource matrix. Your question is broad, and not fully answerable in it's current form. However, I think it's answerable if you redefine the underlying problem that you're facing.
Specifically, I believe the underlying issue to be one of chunking. Whether you're talking about distributed computing or distributed project teams, the question of how to decompose tasks into discrete units of work, each of which can be performed independently, is a common one.
A Generic Solution
From a project management standpoint, there will be a large pool of potential answers to this question. However, at a macro level, they will all have some similar features.
- Work units are small and independent of one another.
- Work units are largely self-contained.
- Work units can be completed within a short, well-defined duration.
- Work units must be either done or not-done; incomplete work should not be turned in or reassigned.
- Work units need not be unique, and the same work unit can be handed out to more than one worker at a time.
- Work units produce outputs that are provably correct.
- Work units must not block; each work unit remains available to anyone until it is completed and removed from the work queue.
- Work units can produce identical work products without causing problems, and duplicates are acceptable project artifacts that are handled properly during turn-in, collation, or integration.
- Collation/integration of the completed work units is centrally- and actively-managed.
GitHub Repositories as Concrete Examples
If you think about it, this is how a lot of open-source projects are managed on GitHub. Issues are created, one or more volunteers pick a given problem from the issues list, and the issue is closed only when the maintainers approve a completed patch and integrate it with the existing code base. If someone starts work on an item, but doesn't complete it, the system keeps those same items available to others until the issue is marked "closed."
The one problem this model faces is that it can't guarantee that any given unit of work will actually be worked on or completed. However, that problem is implicit in your drop-in/drop-out model, and may require other incentives or project controls to address effectively.
Computational Examples with Project Management Implications
While more in the nature of computational solutions, you might want to look at the way projects like SETI@home, distributed.net, or BitCoin have attempted to solve these problems. Even if your problem is not computational, the packaging and integration of work units for these projects is the same class of problem that you're attempting to address.