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.