How SparkFun Electronics built their open hardware business

No readers like this yet.
neon sign with head outline and open source why spelled out

Opensource.com

At SparkFun Electronics we do not sell software, yet we have a robust software development team. These developers spend some of their time on SparkFun.com, an eCommerce platform with extra content and integrated community elements. The vast majority of their time, however, is spent on Sparkle.

One might call Sparkle a web-based ERP system. It's the other view atop the same databases underlying SparkFun.com but with sprawling internal subsystems that do everything including basic customer service, running the shipping warehouse, and running the manufacturing floor.

Sparkle, and the systems running it, take great advantage of free open source software. PHP is the core language. Nginx is the core webserver with Varnish for caching. Everything runs on Debian Linux and the data lives in MariaDB (MySQL's more open cousin) and MongoDB for the non-relational stuff. And caching happens with Memcached and Redis. On the client side, libraries like jQuery, D3, and Bootstrap are ubiquitous. Internally, systems side tools like Munin, Nagios, Samba, Puppet, and Capistrano (to name just a few) keep the lights on.

To call it an open source stack is to sell it short. It's an open source architecture and it's enterprise-wide. Even our phones run on Asterisk, an open source telephone framework. 

Now, this all jives well with the rest of the business. SparkFun's been pushing open source hardware for a few years. Products designed by SparkFun engineers are released with schematics and firmware under a Creative Commons license. For all the new electronics SparkFun has produced over the years the company doesn't hold a single patent.

All of the above yields warm fuzzies for our open-source-minded staff. As an organization, we're contributing to the open source community...right? Well, the bleeding-edge open source hardware community certainly enjoys a wealth of new material from SparkFun. However, searching for open source software from the SparkFun development team turns up comparatively less.

For visualizing any type of activity on a website we have Blode, our syslog-like event broadcast daemon. There's also StormFS, a FUSE abstraction layer for cloud storage. Then of course there's SparkLib, a modest collection of PHP libraries namespaced out of the rest of Sparkle. These libraries, few though they are, are general-purpose enough that somebody besides us might actually want to use them.

That is a far cry from, say, Twitter releasing Bootstrap and in turn transforming how rapid front-end development happens for a significant chunk of the Internet. Arguably our open source software hasn't had a measurable impact yet. So what has Twitter done right? They were dissatisfied with existing CSS frameworks so they invested developer resources to build their own. It was awesome, and they're not in the business of selling CSS frameworks, so they open sourced it and there was much rejoicing. 

At SparkFun we looked at and grew dissatisfied with web-based ERP systems. So, we decided to build our own, called Sparkle. Parts of it are kind of awesome, and we're not in the business of selling ERP systems. Will we opensource it?

I've been asked this question many times. And actually, that is a long term goal. It even informs technical decisions on a day to day basis. Unlike Bootstrap, however, Sparkle is still developing from its procedural roots to be a clean, modular, MVC-based system coupled less tightly to its schema and specific usecase. Open sourced today it would be far too cryptic and unusable to someone who wants an out-of-the-box LAMP stack ERP system for their burgeoning business. But rebuilding pieces of it to be more general-purpose also generates cleaner, easier to maintain code and is thus a worthwhile pursuit.  Put another way, cleaning up our code base and making our code base open source able are practically the same thing, so we'll do both and everybody wins.

In the meantime, our eagerness to give back to the generous open source community is ameliorated by the open source hardware flowing from other parts of the company—a process continually made more efficient by developing on Sparkle. This indirect way of contributing is, to date, the best way to convert developer resources into valuable open source material while keeping the business running.

Sparkle will see light beyond SparkFun's walls, eventually. I do look forward to the day a fledgling company uses a Sparkle module to run its manufacturing floor or predict usage trends on inventory. That scenario can only play out if what we release is in fact transferable, however. Thus, it waits. Releasing quality tomorrow beats releasing noise today.

See our Kickstarter projects here.

User profile image.
Director of Information Technology for SparkFun Electronics, former image processor for the Cassini imaging team, math and technology enthusiast. Follow on Twitter: @Frencil

4 Comments

I think it's very brave to open source hardware - it seems there is a greater investment in the work, unlike software that can be created and destroyed virtually without a real world investment beyond server and power. It's great to see such work being done in such a fun way.

A question about your open source hardware efforts. You link to the CC BY NC SA license, which is (strictly speaking) not a free and open source license due to the non-commercial restriction. Is that the license you are currently using for your open hardware? If so, do you plan to switch to a license that aligns better with the OSHW definition?

Very glad to see you are thinking as you are working about how these decisions are going to affect a potential open sourcing in the future. If I could make a wish for you, it would be to find a way to simply rip back the covers immediately and do all the refactoring work in the open. <a href="https://www.theopensourceway.org/wiki/How_to_loosely_organize_a_community#Practice_radical_transparency_from_day_zero">Being open from the beginning</a> is a defining principle of the open source way because you can never capture the thinking and reasoning that went on behind closed doors to show transparently one month or one year down the road. All that goes before the Great Opening will be apocryphal knowledge lost to the sands of time, reasoning and explanations that always start with, "Well, when we had an internal meeting to decide two years ago, I guess we were thinking ..."

Our hardware utilizes <a href="http://creativecommons.org/licenses/by-sa/3.0/">CC BY SA 3.0</a> which allows for commercial uses. It's just our images that have the non-commercial stipulation. This is due to the fact that if a third party reproduces our hardware for commercial purposes it probably won't look like exactly like what we produce so the burden is on them to take accurate photographs of what they've built.

As for being open from the beginning, I see the argument in favor of that. Ultimately it comes down to making sure our ideals map to practical reality, however. Some corners of our ERP system may present a very real security risk by exposing the source simply because it is legacy code that was not built with a particularly secure architecture. Other corners have company-specific account data (e.g. keys for APIs) that haven't yet been broken out and stored more sanely. These are the biggest factors in keeping things closed and until they are all addressed no potential for goodwill by ripping back the covers will trump our security concerns.

Thanks for the licensing clarification. That was what the SparkFun site seemed to show as licensing, but in the article above you link to the NC variant of the Creative Commons license when writing, " Products designed by SparkFun engineers are released with schematics and firmware under a Creative Commons license." Perhaps worth a fix?

I understand about the security concerns. I think Red Hat had similar challenges creating Spacewalk, which was the open sourcing of Red Hat Satellite. Satellite was tied to financials, etc., before opening. As I said, it was more in the form of a "wish for you" than a commandment. :) Perhaps, though, you'll find ways to abstract out those modules early so other sections can be ripped open en masse, or something. Good luck!

Awesome work by SparkFun team ! ! !

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.