Strategy for Growing the FarmBot Community

Since writing the FarmBot Whitepaper I have known that this project would never become a reality without the help of others. For one, I recognize that I do not have all of the skills and resources necessary to create a functioning system on my own - not even close. And two, and more importantly, the FarmBot project has such a massive scope and potentially wide-reaching effects that being open-source and tapping into the power of the crowd is the project's most important asset. The open-source strategy is not only the best for humanity as a whole, it allows us to build the best hardware, software, and data system more quickly and efficiently than a traditional closed-source model.

The Importance of Community

Building a community around the project is therefore critical towards our success by allowing us to:

• Bring more ideas, opinions, skills, and resources to the table to provide diverse insight and capacity for moving forward
• Develop the project at low cost through volunteer contributions and distributed capital donations
• Build resiliency and redundancy into the project team so that people may come and go without significantly affecting the ecosystem

So the question that this blog post will try to address is in fact our Mission Statement:

How might we grow a community that produces free and open-source hardware plans, software, data, and documentation enabling everyone to build and operate a farming machine?

Community Building Strategies and Challenges

Inclusivity

It can be easy to judge or make assumptions about how worthwhile it might be to respond to someone's questions or comments or entertain their ideas. This is especially true when you have clear documentation available that if that person had done a minor amount of research, they would not have mentioned anything at all or at least mentioned non-duplicative things. This is also true with folks who just want to "kick tires around," meaning they don't even necessarily want to talk about the project, but everything else that is of interest to them. Inclusivity however, is the policy of including those who might otherwise be excluded from participating such as those who did not do any research but went straight into reaching out to me. Up to this point in our development, I have been very diligent about hearing everyone out and responding thoughtfully. This has been great for spreading the word about the project far and wide, and has even led to converting people from just being interested to actually reading our documentation and making contributions. As more and more people find out about the project, there is a proportional increase in people reaching out. The question I then come to is: Is it scalable to be inclusive? I'd like to think: yes. That as long as we continually strive to create excellent documentation and provide good communication platforms that distribute the communication load, then we can ensure everyone feels and is included in our work at the FarmBot Project.

Communication and Collaboration Tools and Platforms

We have tried many different communication and collaboration tools and platforms. Each have had their strengths and weaknesses show for our project and team. This list is also on our wiki and may have been updated since this blog post.

• Email Newsletter - We use MailChimp as our email newsletter service provider. It's free for a limited number of recipients and easy to use. This is a top down, one to many communication channel, followed by a one to one channel if anyone responds to the newsletter. This is most useful for large, project wide updates that are more informative rather than discussion oriented. We are currently still using MailChimp and have no plans to move to another service.
• Google Groups - This was used very early on in the project as our first many to many communication platform. It worked for a while but then was overrun by spam bots. The requirement for a Google Account to use the platform was also likely a barrier to entry for some. We no longer use this platform for communication and would advise others against using it for projects that are likely to scale past a dozen contributors.
• GitHub Issue Tracker and Wiki - GitHub's built in issue tracker and wiki has turned into the most robust and easy to use way for the software development team to communicate. It is a many to many platform and integrated tightly with the code development itself. It has built in labelling, milestones, image uploading, @mentions, and other thread referencing built right in among other features. It is an extremely popular platform that most programmers will be familiar with, though it does require a GitHub account and may be difficult to use for a lay person or non-programmer. In our experience, anyone looking to actually contribute code has been warmly welcomed into the discussion. GitHub is very tailored to working on software asynchronously. This makes it less suited and less capable than other platforms for communicating and collaborating on UI/UX designs, hardware development, R&D, and real-time communication. We recommend using GitHub for communication and collaborating about software only.
• Waffle.io Issue Tracker - We have supplemented the GitHub issue tracker with the Waffle.io tracker, though it seems to be largely ignored because it adds marginal functionality when compared to GitHub's native capabilities. It is really just a visual interface for everything. Perhaps when we have more than a few dozen open issues and more contributors, it will become more useful.
• IRC - IRC is ancient chatroom technology that scares many away and yet it is tried and true among many software developers. Some of our devs hangout in #farmbot and #openfarm, though not much usually happens there. We once tried to have a meeting between devs and designers in an IRC room - there was confusion as to how to log on, a netsplit happened, and then the conversation was not stored anywhere preventing anyone who missed the meeting to be able to read through it. IRC is good for developers because they can stay logged in and anyone can quickly get on and ask a quick question. It is pretty much useless for anyone else and has no other functions than the basic chatroom.
• Google Docs and Drive - Google Docs and Drive is absolutely fantastic for real-time collaborative document editing and sharing. We have collaborative worked on Google documents for writing out strategy, blog posts, and meeting minutes; Google drawings for UI/UX design and diagraming; Google spreadsheets for data models, and Google Drive for sharing other documents. I highly recommend using their services for all of the above.
• Wikispaces Wiki - Shortly after publishing the whitepaper, I setup a project wiki using Wikispaces. The reason I chose Wikispaces was for their WYSIWYG editor because I did not want to learn (or make others learn) wiki syntax - it felt like a barrier to entry. The other reason was because I did not have the technical chops to setup a full blown mediawiki installation. The Wikispaces site turned out to be a disaster. It did not have very many features, it was expensive, and it was non-standard to use for a project like this. We ended up moving everything to a mediawiki installation as talked about next.
• Mediawiki Wiki - Mediawiki is the standard wiki software out there. It is well used and well documented, though one needs to set up their own instance of it on their own server and maintain it. This was difficult for me as a non-programmer and occasionally my server goes down without me knowing and I need to restart it. However, the benefits of being on the standard and most powerful wiki software are great. It is familiar to most people, and as the project and number of contributors scales, I know the mediawiki will too.