Over the past 2 days, I attended an open source accountability workshop at Carnegie Mellon University in Pittsburgh. I wasn’t entirely clear, going in, what I was getting myself into, since the term “accountability” could mean any number of things. It turns out, we discussed many different meanings.

You can see a high-level view of what the workshop was about on the event website, although I don’t know how long that resource will be available now that the event is over, so I mirrored it HERE for my own records.

Accountability means several things in this context. Questions considered include:

• Who do you call when stuff breaks?
• How do you account for the time of open source engineers (whatever that means) when there’s no guarantee that their work will be accepted?
• Who should (whatever “should” means) fund or support (whatever those words mean) open source development?
• What can open source projects/organizations do better/differently to facilitate stakeholders (who are these?) engaging with the project in helpful ways?

Now, obviously, we were not the first people to address these questions. And we won’t be the last. But the conversations were very interesting, and gave me not only a lot of new ideas, and related questions, to ponder, but also gave me a significant to-do list of stuff that I now want to try to do within the community development committee at Apache.

So … as usual, I went to an event and came home with yet more work to do.

I expect to have several followups to this post, about various specific topics that are echoing in my brain. These include some of the following:

• Accountability and rewards for community-facing roles with ill-defined metrics
• Creating a more welcoming “front door” for various audiences
• Vendor/OSPO liaison activities from open source orgs/projects
• When your village becomes a city