Originally published at: http://mycroft.ai/blog/small-projects-vs-big-products-challenges-for-open-source-software/
I’ve always been a bit jealous of Mike Muuss. Mike was the author of a prolific Open Source Software tool that is used by millions of network administrators around the world. His software is a paragon of efficiency and has improved countless lives. What is this prolific and useful Open Source tool? Ping. Seriously. While working at the Ballistic Research Laboratory in 1983 Mike needed to diagnose a network problem and wrote a short program that used ICMP to do it. Ping was Mike’s contribution to the Open Source Community and is now implemented on billions of computer systems around the world, in orbit, and even on Mars.
There are plenty of reasons to build any software in an open way. Being open fosters community and collaboration. It allows broad innovation outside any rules or preconceived limitations. Open Source Software has the capability to improve lives on massive scales when transformative technologies emerge.
But the effort required in making life-changing software can vary wildly. Some are a “little thousand-line hack that I wrote in an evening” in the case of Ping while others are massive undertakings that work best with some underlying infrastructure and services at the outset. For that reason, they wouldn’t survive without a business model behind them. At Mycroft, we’ve come to understand the differences and learned how to make a product a going concern without losing the open ethos.
The Project
Ping is an example of a software tool that makes a great Open Source project. It is short, simple, and to the point. It can be understood and maintained by nearly any technician and is so widely used that it is nearly ubiquitous. They don’t need extensive infrastructure, support, or professional effort to be continuously useful. Maintaining the code doesn’t require full-time staff, and running it doesn’t require online services, or any of the ancillary functions like marketing, sales, and accounting that are required of even the smallest business enterprise.The Product
Other Open Source tools aren’t nearly as well suited to being projects. Technologies like web browsers, office productivity suites, and desktop environments are complex. They require multidisciplinary teams that work closely together to solve problems. Though there are some high profile examples of complex software that is operated as a project, the most successful Open Source Software is organized into products that are sold, maintained, and/or supported by paid professionals.Mozilla Firefox is one example of an Open Source product, but there are many others: LibreOffice, Wordpress, Ubuntu, Qt. All of these are products supported by professionals who are paid by customers. These products are distinguished from Open Source projects by their size and complexity. More complicated applications require larger teams. When complex projects arise without teams behind them, they often flounder. That means the bigger the application the more likely it is that it will become a product, not a project.
Product development also requires the team to think through commercialization. Living by an open ethos is much easier with a non-commercial project – the team doesn’t need to give much thought to how the software will generate revenue. For a product commercialization is key – how does a team balance the need for a revenue stream with an open and transparent software stack?
This complexity and necessary commercialization has the potential to alienate communities of developers if they see the software moving in less innovative, exciting ways for the sake of monetization.
Voice Projects vs. Voice Products
In the voice space there have been several attempts at Open Source projects. The MIT Media Lab published Jasper way back in 2014 and Georgia Tech student Steven Hickson published Voice Command in 2013. But, until we launched Mycroft, there were no Open Source products. Launching a product, it turns out, is much more time and resource intensive than launching a project. It involves fundraising, marketing, design, sales, and significant professionalization of the underlying software (autotest, release cadence, testing, framework development, etc.). But, they were necessary to pay for and provide easy access to things like the fast accurate STT and aggregated APIs that make Mycroft immediately useful.What We’ve Learned
At Mycroft we’ve learned a few things about building a product that is both open and transparent.- Being open is your strategic advantage. Embrace it. Customers want access to the entire software stack. They want to be able to view, edit, and improve the software. Let them. It is what distinguishes an Open Source company from run of the mill proprietary software stacks. That is why we’re planning to open up our back-end next year so that anyone can install Mycroft - the agent AND the server.
- Add value. Anyone can install and configure a software package. Making a smart speaker? That is hard. By shipping dedicated hardware that makes it easy to deploy our software we’ve established a market niche for Mycroft as the open voice assistant. That adds value for customers by making it easy for them to deploy voice assistants of their own.
- Vision, vision, vision. It is way easier to build a voice command system than it is to build a voice assistant. At Mycroft we are building an AI that interacts so naturally that people won’t know if they are speaking to a human or a machine. That is a big vision and it keeps our Community fired up. Are we there yet? No. Not by a long shot. But we are making progress and that inspires passion. When we get there (and we will get there) it will be a significant achievement and a fantastic product for our paying customers. Make your Community part of that vision by offering them a stake in the software and the company.