by Gitter

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?

I’m a career web developer of 20 years and now the CTO of LUXE City Guides. I’ve always been involved in the open source community in various forms and over the last few years been deeply involved in the JavaScript Robotics (nodebots) community.

Node-Pixel grew out of that, with the project very specifically merging hardware and software (JavaScript) together to create beautiful lighting effects. It began because historically there hadn’t been an easy way to do that in the JS Hardware world and I’m a sucker for pretty lights so decided to build something that would do it.

The community is definitely a subset of the Johnny-Five and NodeBots communities with those who are specifically interested in hardware lighting being part of it (other groups are more interested in traditional robotics or home automation etc.). The project has seen commits from some amazingly talented developers from around the world who have helped realise the goal of a straightforward way to control hardware lighting from JavaScript.

What common goals do you have as a community ?

Pretty much as explained above, really a desire to see people use hardware with JavaScript and in particular be able to work with very sophisticated hardware using a straightforward way to do this.

What issues related to the Node Pixel project are you most excited about these days?

Definitely the wider integration into Interchange, which is a project I’m also involved in. Interchange solves for hardware firmwares what pip and npm solve for python and javascript modules — that is, package management for specific targets. The Node Pixel project illustrated the need for this within the JS hardware world and caused Interchange to happen, so making it fully compatible with Interchange is a big goal.

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.

Related to this is that we abide by a Code of Conduct for contribution to the project and since the outset we’ve always endeavoured to foster an open, trusting, safe and responsible community. I think when people set that out as just “the way things are” then it helps people adopt that set of standards when they engage. Node Pixel has been good in that respect but really owes a great deal to the wider work being done in the JS Hardware world by Johnny-Five and javaScript in general to ensure safe places.

What are the key challenges that you encounter while managing the community?

Time zones!!!!

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.

Thanks!