Building Online Communities: Node-Pixel.
Andrew Fisher works on a project merging hardware and software to create beautiful lighting effects. He told us about his way of fostering and managing the open source community around his project. Find out what he says & check out the Node-Pixel Gitter channel.
Tell us about a little bit about yourself and the Node-Pixel community. What is Node-Pixel? How did it all begin?
What common goals do you have as a community ?
What issues related to the Node Pixel project are you most excited about these days?
Beyond that the next big push is in making the library more capable of things like animation and what not, to create really sophisticated lighting effects and have them all triggered from NodeJS or potentially from the browser directly.
What are the most important factors that you have taken into account while creating and maintaining the community? What factors contribute to the success of your community?
The biggest things really I think have been transparency — we use Gitter and GitHub issues as a big part of this to foster collaboration between people that are geographically separated. Having logs of our discussions etc. makes it easy to go back to the community to explain the rationale behind something, especially if they are a user of the project but may not contribute to it.
What are the key challenges that you encounter while managing the community?
I’m in Australia and most of my collaborators are in the US and EU so getting overlaps can be really challenging when we’re working through building features etc. Need to make the Pacific or Indian oceans about half the size they are ;)
What are the main issues discussed in the Node Pixel project channel on Gitter?
Much of the day to day stuff revolves around support for people using the project. We are very vocal about our use of Gitter as a primary support channel so encourage people to drop in and ask questions. This helps get people up and running with the project very rapidly.
Besides that, as we’re building features, there’s a lot of back and forth discussion about approaches, notes on code reviews etc. GitHub helps with this, however we tend to use GH as the second part of this more free-flowing chatter while we arrive at an approach then use GH to document the issues and the steps to resolution.
Based on your experience, do you feel that the open source communities have changed and evolved over the past years? If so, how?
Definitely. There’s some good and bad in this. On the one hand open source has more or less “won” much of the way we build software. As developers we want to be able to see, validate and change the code we’re running in our own projects. In this way I think software development has become much more open for everyone and hopefully that is helping future developers to learn and not repeat the mistakes of the past due to lack of information.
The bad part is that there can be a lot of consumption of the “free” part of free & open source software where consumers of the projects do expect fixes to happen immediately or a new feature added just because they asked. Being able to use the tools to engage with people to soften this approach is invaluable, as you can often encourage someone to help contribute and potentially build the feature they want to see as part of the project.
Overall, I think the community is more of a community now and I believe the good definitely outweighs the negative aspects — but we should always be looking at what can be done to help all projects have a better experience.
What advice would you give to someone who wants to start an online open source community from scratch?
Talk to yourself.
That sounds weird but it’s often daunting when you’re the only person working on a project. You have an idea, you throw your code up there and you wait for people to nit pick it. It can be very challenging because you’re opening up yourself to potential critique.
One of the ways I get over this is to raise issues in my GitHub and assign them to myself. I do code reviews of my own code and make notes about it and raise tickets to fix the code. I also quite often note current statuses etc in Gitter even though I suspect no one will read it.
However the funny thing with this approach is it helps you be more refined in the way you talk about your project to others later, and you also build up a body of documentation, rationale and “liveliness” about your project and it makes it easier for others to contribute — even if they think they are collaborating with a mad person who talks to themselves (which we all do anyway).
So my advice is talk to yourself. It helps articulate your project, makes you approachable and a community has to start with a person so *be* the person it starts from.