I was listening to Changelog episode 242 and when James Long describes an typical yet ideal experience of posting libre code to Github as an unexpected burden, it jumped out to me that Github, Google Code, Sourceforge, and a dozen other libre code hosting sites can step forward to change that burden by altering the human language around posting a new project.

An earnest developer wants to be known for creative thinking and their thesis is a code dump. Yet the environment of coders is young, scrappy and hungry: if it’s useful, the originator is bombarded by the obligations of maintenance and interaction of the audience.

If things that were experiments, proofs of concept, or insights, were not subject to maintenance requests, what would happen? Would the authors gain a kind of reprieve from obligation to participate? Should services like GitHub develop a code diary publishing form such that these ideas can be read in terse form but not pulled?

What form should appropriate feedback take? Comments, or a higher bar, such as patches? Or should we prohibit code in order to reduce obligation and encourage a longer form conversation: a code diary reply post?

The anxious among us immediately worry that anything synthesized even as pseudocode is somehow salient knowledge: anyone reading and not replying might be copying and posting an app while the original author is doing his best to maintain a healthy sleep schedule. Is this anxiety actually unfounded, though? Unlikely.

My point is really to focus on the how we can better steward notions of experiments, proofs of concept, and insights in a libre coding realm. The notion of having a one shot idea is perfectly valid for some people: they publish a proof of concept, something larger than a gist, yet beneath the definition of library or application. Maybe those notions can be automatically published only a markdown, or PDF. Or maybe they cannot be pulled or cloned. Or maybe the appropriate mechanism is for the publishing platform to synthesize an animation of the usage and help the author produce a technical blog post?

What other language distinctions have I not touched on that might be pertinent? Are there other situations that could be considered? As a parent challenged with compulsive coding urges, I love this topic. Chime in!