Best practices for an open-source, community-driven project
June 10, 2015 9:15 PM   Subscribe

I've found myself working on a very exciting (to me) open-source web project. It's only a few days old, so right now it's just a bunch of people throwing ideas around in a Slack, with a couple of vague channels. Pretty soon we're going to need to come up with some organization and structure, and I'd like some advice on this.

I've never worked on a project like this before, and I'm excited to contribute. I can't help on the technical side, but I have a marketing background. More importantly, I'm organized and like leading/managing projects, so I think that's where I'll be most helpful. However, I'm sort of at a loss in a situation like this. I only know a few of the 50+ people, although some of them know each other. We all have a vague idea of what we want but not quite a defined purpose.

How do you organize a loosey-goosey project like this? How much should be structured, and how much should stay free-form? How do you build consensus, make decisions, and generally be productive when nobody is "in charge"? I imagine that some leadership and decisiveness must be necessary to get things done, but how do you avoid coming across as bossy?
posted by radioamy to Human Relations (3 answers total) 4 users marked this as a favorite
 
This article on Starting an Open Source Project from Smashing Magazine covers a lot of the nitty gritty, from choosing licenses to organizing code to documentation to communication within the group. I think it starts a little later in the process than "we are talking about a cool idea," but it might be a good way for organizers to wrap their heads around the implementation details for open source projects.
posted by instamatic at 3:08 AM on June 11, 2015 [1 favorite]


Set up a GitHub repository and a Redmine project to track revisions and the build/bugs, respectively. Public projects are free on GitHub, and you can get Redmine hosted for free as well. And yeah, Slack is probably a much more vibrant way to build community and maintain discussion than the mailing lists mentioned in the Smashing Mag article, which was written before Slack's ascendance. But beware that if you're using the free version of Slack, some of your documentation of decisions made in conversation will be inaccessible before long, so it might be worth upgrading and paying to get archive access. The thing to keep in mind, of course, is that someone has to pay for at least that Slack infrastructure—if you don't have a monetary structure for people to contribute yet, that might be good to set up. You can definitely keep talking in Slack without paying up, of course, but the ability to retrace any discussion in the paid version is pretty great, especially for projects with a lot of contributors.
posted by limeonaire at 5:29 AM on June 11, 2015


Response by poster: I think the technical people have the code tracking part of it covered. I'm more concerned about the actual management/communication/decision-making aspect.

Good point about the Slack. I'll mention that to the person who is "officially" in charge of the project.
posted by radioamy at 7:27 AM on June 11, 2015


« Older Tips for Mongolia, Ulaanbaatar and Naadam   |   Do high speed trains have a place in America? Newer »
This thread is closed to new comments.