open inclusive collaboration

In a recent discussion at Berkman an interesting thread started discussing standards development and how to approach it, or if to approach it at all. What follows is my hastily written response to the following remark:

Why should I care about standards at all? In the early stages of a technology, maybe I should just invest my limited energy into creating a great system that has high levels of adoption — leveraging that market position later to drive the agenda on any future standards and interoperability conversations.

So, I think that in cases such as the one being discussed that drafting a standard should start late in the process, but, the best practices in standards development should be done from the start of a project. To explain what I mean, here are some thoughts and examples of organizing/managing a project so that it is designed to coordinate and collaborate on standards without necessarily adding too much overhead.

Assume a distributed team of volunteers

Make sure you have a simple and concise explanation on a web page that states: the name of the project and what the project is trying to accomplish; how a person can get involved in working on the project; and link to a public discussion mailing list where the project is actively being discussed.

And, then actually go ahead and use that public discussion mailing list. Even if you have a team of employees sharing an office with white boards, I still say, make sure the notes get sent out to the discussion list.

One of my favorite examples of establishing rules for collaboration comes from Richard Fontana’s copyleft-next project, which is called Harvey Birdman Rule — my favorite part of the rule is subsection 3: “Except in extraordinary cases, private telephone calls, private teleconferences, private in-person meetings, and private email communications shall not be used to discuss substantive development of this project. Should such private communications nevertheless occur, participants in such communications are expected to publish summaries of any relevant discussions in a manner or medium accessible to the general net public.”

Organize your source into logical version control repositories

There are lots of examples on where this applies, such as protocols, APIs, etc. But, let’s start with a simple data model example. If you know you are going to be collecting some data into some internal database or model, it often makes sense to go ahead and move that entire data model into its own repo. It might be something as simple as a JSON file with some tests. But, by separating it out into its own repo, you are going to make it easy for others who want to discuss and collaborate on just the data model (or future standard to be), to do so without having to do it in the context of the rest of the software you are developing.

Create a /data directory

These days, the White House’s open data initiative rules require government sites to have a /data directory on their sites, but the first place I ever saw one was on Aaron Swartz’s Watchdog.net. The original project was very different from what it is today, so you’ll need to use the wayback machine to see what I mean.

I also think that the old watchdog.net project’s git repo is a fabulous model for organizing things (read the README file) in a way that both allowed people to quickly develop stuff while also making it easy for people to go in and just grab useful parts of the project they need to do their own crawling, scraping, parsing type work — I continue to use it from time to time 🙂

Create a targeted “newsletter”

One thing I see a lot of people do is spend a lot of time early on in a project looking for people and projects that are doing work in their space. But, then  after they get started on a project, they stop pro-actively reaching out to those people and projects. This is unfortunate, because it means you have often gone through all the hard work of finding these people and projects and making an initial contact, but, you don’t end-up reaping all the rewards of that hard work.

While opt-in announcement lists and whatnot are good to have, I think it’s still good to continue push occasional updates out to the people you’ve identified as “interested in possibly collaborating or cooperating in the future,” and to tailor an update email to just them. You can even add them to an announcement mailing list or create a special mailing list — it doesn’t matter how you organize it so much as you continue to “go to them” instead of just expecting them to come to you.

Later on, it might even be that this special list of people might become the public discussion list when you begin the formal standards development process.