• Ambient and Infrared, Layout Updates

    Tuesday, December 3, 2013

    12/3/2013— Updates


    We sent out a new design for a test run about a week ago.

    The major changes are: UART is now on every port. A lot of commonly used chips use UART for communication. Every port now supports UART, SPI, and I2C communication protocols. We have hardware UART on three module ports and software UART on the fourth module port and the gpio port. We have two different I2C ports. Port banks A, B, and the GPIO bank use one I2C port, while banks C and D use another. Because I2C uses the same two lines to talk to all the ports, this can create a problem if you want to hook up two of the same I2C devices to Tessel. For example, two Accelerometer modules would clash with each other trying to talk at the same time. Now one Accelerometer module can be hooked up to bank A and another can be hooked up to bank C without clashing. USB power and external power now switches smoothly. In our last revision we had an issue where Tessel would brown out during power switches.

    We’ll be getting back the new Tessels late this week/early next week from our manufacturer.



    We’ve split up Ambient into two different modules, one for sound/visible light, and another for infrared (IR) sending/receiving. Everyone who ordered an Ambient module before now will get both the Ambient and the IR modules.

    We felt that combining these into one module stuck too many features together, and most people we talked to either wanted ambient sensing or IR transmissions. Our goal for Tessel is to make hardware abstractions that make sense, and combining low precision data (such as ambient) with data that needed signal processing (such as IR) felt that we were trying to do too many things at once.

    Splitting the modules up frees up space on the ambient module, which we’re using to compute the “loudness” in hardware, as opposed to doing so in software. This means that the ambient sensor will let you quickly determine the ambient noise level or run your own algorithm on the incoming analog signal.


    We’ve made the switch from the BLE112a to the BLE113a module. The BLE113a is not only smaller in size, but it also has a lower power draw, so you have a little more wiggle room with your other modules.


    We sent out the Accelerometer about a month ago to a manufacturer for the production run. They’re done making them and are now testing them. We should get them back in the next week or so. If these turn out well, we’ll begin to do production runs of the other modules we’ve finished.

    As always, you can see our progress here http://tessel.io/status

    –Jon, Kelsey, Tim, Jia, and Eric

    #tessel #technical machine #updates #layout #communications protocols #infrared #ir #ambient #sensor #module #manufacturing #update

  • Getting Custom PCBs for Prototyping

    Monday, December 2, 2013

    12/2/2013— Jia Huang

    When we first started making hardware, we knew we needed custom printed circuit boards, but didn’t exactly know how to go about getting them. I thought I’d just share some of the tools and resources we use for getting PCBs made.

    PCB files

    Most manufacturers will ask for Gerber files. These are the files that specify how each layer of the PCB should be made. These layers are then stacked together to form the PCB. From top to bottom, Gerbers are usually split into the following files:

    • Top silk - the (usually) white informational text on PCBs
    • Top paste - this is used if you have a stencil for the PCB. The top paste is laser cut out of a stencil and then put over the PCB and solder paste is put on top. Components are placed on top of the solder. The paste layer is useful if you have a bunch to make and don’t want to apply all the solder yourself.
    • Top soldermask - this goes over the copper layers
    • Top copper - the top signal layer
    • Inner layers (if you have any) - inner layers are for ground, power, or extra signal layers.
    • Bottom copper - bottom signal layer
    • Bottom soldermask - same as the top soldermask
    • Bottom paste - same as the top paste
    • Bottom silk - same as the top silk

    Additionally, if you have any holes, you’ll need to have a drill file.

    The files for the accelerometer look like this:

    Note that this doesn’t include the drill file even though the accelerometer has one. The bottom paste also isn’t included since we don’t have any components that need to be mounted from the bottom.

    We use Diptrace for schematic & pcb layout. Then I use the MCN Gerber viewer to double check files before sending them out. As far as I know, MCN is the only native OSX gerber viewer. MCN has some issues displaying drill files so I also use gerbv to double check. Eric uses Graphicode on Windows.


    We spent a while looking at different ways to source the custom printed circuit boards we needed. Different fabrication houses tend to specialize in different things, and vary in:

    • lead time (a few days to a few weeks)
    • number of boards needed
    • quality

    The price for the same board differs depending on the manufacturer and their setup. Depending on what we need to do (prototype, test run, side project), we’ll use different manufacturers. Since most of our modules go through multiple revisions, it’s not uncommon for us to use different fab houses at different stages of development for the same module.

    Here are some of the PCB manufacturers we’ve used so far:

    AP Circuits

    Lead time: 3 days

    Number of boards: 2 or 4 boards. While you can order a lot more, we only do 2-4. Anything higher and we tend to use Seeed or Silver Circuits.

    Quality: Electrical testing isn’t included, and sometimes we’ve had soldermasks shift. But for the turnaround time and price, it’s a pretty good trade off.

    If you want to forgo the silkscreen and the soldermask, AP circuits can make the boards in 1 day. AP Circuits also has very good engineering support. They’ve caught more than a few of my mistakes.

    Seeed Studio

    Lead time: 2.5 weeks

    Number of boards: 10+

    Quality: There’s free electrical testing included, and Seeed usually makes extra boards in case some fail.

    Seeed also allows different colored PCBs at low volumes as well as great pricing for 4 layer boards. In addition, they also have a stencil service which is useful if your boards have a lot of pads.

    Seeed also has an assembly service for 100+ units.

    Silver Circuits

    Lead time: 1.5 weeks

    Number of boards: 4+

    Quality: There’s an option to include electrical testing, but I’ve never had any boards that were defective.

    Silver Circuits also offers 1oz and 2oz copper layers at similar costs which is useful for our RFID module.

    OSH Park

    Lead time: 3 weeks

    Number of boards: 3+. Must be a multiple of 3.

    Quality: Never have had any issues with quality.

    OSH park has automated design rule checks that it runs through as soon as you submit your files. Additionally it takes Eagle files directly as well as Gerbers.

    Gold Phoenix PCB

    Disclaimer: I haven’t used Gold Phoenix for Tessel, but I’ve used them before for other boards so I thought I might as well include them in this list.

    Lead time: 2-3 weeks

    Number of boards: 20+. They can do any number, but it’s probably not worth it unless you’re doing at least 20 boards.

    Quality: Optional electrical testing, though I’ve never had any issues with getting working boards.

    Like Seeed, Gold Phoenix also has assembly services though I’ve never used them for that.


    #jia huang #tessel #technical machine #hardware #pcb #manufacturing #gerber files #seeed #seeedstudio #gold phoenix pcb #osh park #ap circuits #silver circuit #Electrical Engineering

  • The Reluctant Programmer: Feminism and Tech

    Monday, November 25, 2013

    11/25/2013— Kelsey Breseman

    I’m not an absolute novice on code… but my credentials are pretty bad. I took Visual Basic in high school, played around a bit with Python and Arduino during college, and really sucked at learning Ruby on Rails …twice. My major was in neural engineering (which is some combination of bio, electrical theory, and MATLAB/neural modeling); I had never programmed in JavaScript. I joined Technical Machine because they needed a tech-savvy writer with some varied HR and maker background: somebody who could focus on some of the non-technical development aspects of a business.

    It turns out there are a lot of components to a business that don’t have to do with making the product. These aspects of my job are important (designing the logistics of getting products delivered, managing HR and payroll, continuing to have a media presence), but I realized pretty quickly that I would be more useful if I understood more about JavaScript and Node.js– both to improve my ability communicate usefully about what we do, and so I could help with technical development if the need arose. So I looked around online and started learning.

    It’s a difficult thing for me to come out and write about my coding deficiencies. I like the logic puzzles of coding, but not the screen time. The decision not to pursue coding as a primary interest is one I made years ago. I didn’t want the kind of expertise that limits me to sitting still all day, staring at a screen. But I’ve reconsidered– partly due to the advent of the treadmill desk (I don’t have one yet, but I will someday), and partly because the refusal to learn code feels increasingly like an intentional lack of agency in the modern world. And, well, feminism. I think it got to me.

    I can’t help but feel like a traitor to women in tech when I, an engineer by training, describe what I do as the “non-technical” work. Though I’m proud of what I’ve done for Technical Machine, I cringe to describe what I do– usually because I’m explaining it to engineers, who don’t really go in for “marketing” (my excuse to pursue writing) and who don’t adequately respect the difficulties of learning business and logistics (speaking as an engineer who didn’t). And because I’m a woman.

    I don’t think it’s possible to graduate from an engineering college that’s intentionally half women and not be aware of terms like “gender gap” and “imposter syndrome”. So when I arrive at a code conference, I am not surprised to feel like a fake. It doesn’t happen immediately; the conferences are interesting, and I forget sometimes how odd it is to be a woman in tech. But at some point I always remember. Reflexively, I look around and seek out other females in the room: one… two… three of us! No, four! The numbers are not always that skewed, but they usually are. And then, instantly, I feel like a representative. Worse, I feel like a false hope. Because I really don’t belong: is it still imposter syndrome if you really are an imposter?

    I don’t code, not really. I’m there representing Tessel, introducing my teammates’ impressive technical work. If anybody asks me about Tessel and how it runs, I’ve got that down pat. I’ve seen it work; I’ve run the code; I looked up any relevant terms I didn’t already know. Going to all of these conferences (Wikipedia at the ready), I’ve basically had a crash course in what’s important in the web development scene. And I haven’t felt discriminated against at the conferences. There aren’t very many women speaking, but there also aren’t very many women attending, so it’s not a surprise.

    People who approach me don’t pre-assign me a coding level based on my gender. Quite the reverse; they overestimate me, assuming I have at least as much experience as they have. So when they ask me, inevitably, “What do you do for Technical Machine?”, I feel like a bit of a letdown. I preface my answer with, “I’m an engineer, but…”

    And then, when I say whatever comes next (“I’m working on marketing.” “I’m doing business development at the moment.” “I’m doing a lot of the non-technical work.”), I feel instead like I’m saying, “I’m just along for the ride.” Hair flip, ditzy smile. And in my head, I silently apologize to all four of the other women in the room, who are probably real programmers.

    Perhaps, if I don’t code, I don’t belong at coding conferences. No matter that by now I’m excited by the open source community, that I learn a huge amount of code theory when I listen to good speakers. Regardless that attending helps me fill my community engagement role by putting Tessel in the hands of the people it’s built for. If I don’t actually follow through and write programs myself, do I belong at a programming conference?

    So that’s part of the reason I’m learning to code.

    I can’t decide how I feel about that. I know that feminism isn’t about pushing women into fields they don’t want to enter. But I feel like a traitor to all the women who had a much harder time entering STEM fields if I arrive at a technical conference with below-average knowledge of the subject. And in the modern world, code literacy is increasingly like, well, literacy.

    I’m not interested in code for code’s sake, but I do like what comes with it: When I’m not working on code projects far above my head, solving logic instead of syntax is a delight. At conferences, I’ve been inspired: I now have opinions about open source and the indie web. Independent of my gender, I need to program to have a voice in these communities. And of course, to best engage the community that’s growing up around Tessel, I need to speak JavaScript– the language of the web.

    Kelsey Breseman



    #kelsey breseman #women in tech #women in stem #feminism #tessel #technical machine #programming #company culture

  • Inside Eric's Toolbox: An Electrical Engineering Kit

    Thursday, November 21, 2013

    11/21/2013— Eric Kolker

    In engineering we talk a lot about tools. Some people have a favorite collection of software, some a metaphorical belt filled with tips, tricks, and techniques, and others a literal box or lab bench filled with instruments. In my experience, a good engineer not only maintains all three, but seeks to expand his or her collection and share it with peers on a daily basis.

    Today I’d like to share what I keep in my literal toolbox and provide some commentary and backstory for the tools I carry with me. Expect some tangents and links to more Wikipedia pages, too.

    Figure 1: The box. Starts closed, gets opened, returns to closed configuration for transport.


    Unpacking from the top down, the first thing out is a smaller box.

    Figure 2: box of hand tools, closed

    The box contains the things I use most often: a plethora of small hand tools. In it I somehow manage to stash:

    • Wire strippers
    • Needle-nose pliers
    • Hemostats
    • A spool of 30-gauge wire
    • A spool of solder wick
    • A spool of solder
    • A loupe
    • Three sets of tweezers (yes, I use them all)
    • Four dental picks (ditto)
    • An assortment of connectors in various states of dismemberment
    • Some small plastic bags
    • A few scraps of wire, heat shrink, and other miscellaneous parts

    Figure 3: box of hand tools, open

    Big things with two handles

    Figure 4: Left to right: wire strippers, needle nose pliers, and hemostats

    The wire strippers I use for, well, stripping the insulation off of copper wire. I use them only and exclusively on copper because otherwise I would risk plastically deforming the tool and ruining it. Side note: I used the word “maintain” earlier not only imply that you should keep a kit of tools, but also to hint that good tools warrant, and often require, good care. But I digress: never use wire cutters or wire strippers on anything other than hookup wire. Headers, nails (tack, finger, or toe, it makes no difference), small steel shafts, etc. are not to be cut with my tools.

    Needle-nose pliers are great for pretty much everything. I like these in particular because they have good grips (compliant but not too soft and not the kind that dry your hands out or cause blisters), close evenly, and are lightly textured at the ends. They’re also a good size.

    Hemostats (point of interest: they’re supposed to be used to clamp arteries during open heart surgery) are a new addition to the box, and are useful because they ratchet shut and don’t let go. I often use them to hold things in place or grab onto tiny wire when I strip it.

    Things directly related to soldering

    Figure 5: Left to right: 30 gauge wire, solder wick, solder, and a loupe

    This tiny spool of tinier wire is what lets me hack boards with surface mount (SMT) parts. Thirty gauge (technically 30 AWG) is small enough that I can attach it to a tiny pad, but big enough that it can actually be manipulated without a microscope. This particular spool is insulated with plastic (as opposed to enamel-coated magnet wire which is a royal pain to strip), so I can run it all over the board without worrying about shorting things out, but strip off the insulation easily (with heat, even, if need be).

    Solder wick, sometimes called solder/copper braid, is used to desolder (mop up solder) by following these easy steps:

    1. Place wick on affected area
    2. Place soldering iron on wick (on affected area)
    3. Wait until solder in affected area becomes molten (you’ll see smoke rise when the wick’s rosin flux melts)
    4. Mop up molten metal
    5. Remove tools from affected area
    6. Feel like a boss because your ugly solder job is gone

    Up close, this stuff is a flat, woven strap made of tiny copper wires. It comes in different thicknesses, but I generally like think stuff so I can be precise with my solder removal.

    Not all solder is created equal. There are a myriad of different blends of tin and lead (and others), flux and no flux, fat and skinny, etc. My preferred blend is 63/37 (%tin, %lead by weight, which is the eutectic ratio for the metals, and corresponds to the lowest melting temperature for the alloy), rosin core, and super thin. It’s one step below good solder paste for precise SMT work.

    The loupe is effectively a magnifying glass that sits in your eye socket. I first ran into these guys when I took a photography class (we used ‘em to look at negatives before making prints). If you don’t have a microscope and need to make sure a board looks good (all the solder joints are nicely connected, components are properly seated, etc.), you’ll want one of these and a good flashlight to see what’s up.


    (aka “small things with a debatable number of handles”)

    Figure 6: Tweezers!

    Each pair of tweezers is so important that it deserves its own paragraph. Left to right:

    These babies are my go-to. They have a long pointed tip, are acid resistant and anti-magnetic, are lightweight, and have a very abrupt taper at the end. The last two characteristics are especially important when I use them under a microscope because they help me know exactly where my fingers are on the tool at all times.

    These next guys are called “reverse action tweezers” because when you pinch they open up, rather than close down. These aren’t super useful for surface mount work because they’re so big, but are great for holding “normal” size wire (~24 AWG) or through-hole components in place when I solder.

    The last pair of tweezers is probably the most expensive tool in my box that doesn’t use electricity. They’re made of stainless steel, are corrosion resistant, anti-magnetic, and are designed specifically for SMT soldering (and surely give +5 Dexterity). The shape of the tines lets me apply pressure to chips evenly along the sides (crucial for precise placement) without hitting other components on the board (essential for densely-packed boards). When you turn them sideways (so the tines are vertical), you can grab the chip perpendicularly to the board and still see everything in the microscope.

    Dental picks

    Figure 7: Dental picks

    Unlike the tweezers, these dental picks are all pretty much the same (sorry to disappoint). Some have pointier ends or are better shaped for some specific task, but all are used for some combination of scraping, pushing, or cleaning boards or chips. Because they have all come into contact with lead, I can no longer recommend that they be used to clean teeth.

    Miscellaneous smallbox-dwellers

    Figure 8: Miscellaneous occupants of my meta-toolbox

    This is an odd assortment of stuff. Left to right, top to bottom we have a (probably broken) RFID IC, the cover for one of my super swank multimeter probes (read on!), SMA connectors, two small plastic bags, heat shrink, and some black wires (for ground, should I need ‘em).

    SMA connectors are industry standard RF (radio frequency) connectors. They belong to a family of connectors called “coaxial”, whose name comes from the arrangement of the inner and outer conductors (the latter, a ring in cross-section, should always be used for ground). I keep these particular connectors around because 1) connectors in general are expensive (these were maybe $3 each, but some are truly pricey) and 2) because they have been modified (read: I broke off some pieces off of each one) so they’re easy to attach to boards quickly for the purpose of testing something.

    Scopes and meters

    A tiny oscilloscope

    Figure 9: DSO Nano with probes plugged in and the box it comes in

    One holds a DSO Nano, which is a pocket-sized oscilloscope/function generator made by Seeed Studio. As far as scopes go it’s certainly a budget model, but when you need a scope you need a scope, regardless of how small. I use it when I’m in a pinch, am too lazy to walk to the lab, or have simply run out of channels on a larger and less portable scope. It’s also nice to have on hand because it’s battery powered, and therefore it floats (in the electrical sense, that is: it has no connection to Earth ground, which could get you into nasty trouble when dealing with things that plug into the wall).

    ##Multimeters and probes

    Figure 10: multimeters and probes.

    My old, crappy multimeter and the thoroughly destroyed probes it came with, the probes for a new multimeter, and the new multimeter with my fancy probes. The old meter still mostly works, so I keep it around. The new one is honestly untested, as are the probes it came with, but the probes installed in it are the best. Their tips are spring loaded (called “pogo pins” in the art), interchangeable, stupid sharp, and gold-plated, which make them good for getting a reliable connection on tiny surface mount parts. They even have their own datasheet! The downside is that, as probes go, they have a super high resistance (maybe 0.6 Ohms or so).


    Figure 11: Tape!

    I carry Kapton, Crapton, and electrical tapes.

    Kapton is great: it’s corrosion-resistant, has excellent thermal properties, is a fantastic insulator, stays sticky even when abused, and is rated by its thickness, so even mechanical engineers appreciate it. It’s a little pricey, though. I use it to cover up wire hacks (when I use that blue wire) and strain-relieve wires I’ve soldered onto a board temporarily for testing.

    Crapton is fake kapton. It’s still an insulator (read: when something has been taped up, it can no longer be poked), but I don’t trust it on the other counts. Buyer beware: a lot of the cheap kapton on Amazon is really crapton, which is how I wound up with this roll.

    Electrical tape is, well, nonconductive. More often than not, I use the stuff to secure boards to the lab bench when I’m soldering them. Electrical tape is good for that because it ‘s a little stretchy, so I can keep the tape under tension to make sure the board doesn’t slide around.

    Soldering paraphernalia

    Figure 12: An itty-bitty soldering iron and some syringe tips/needles.

    At 12 Watts, this iron is truly puny (even the inexpensive industrial grade ones are usually 60 W, and they do as high as 240 W before you start to get to plumbing gear); you can’t beat the portability. The needles go on the ends of syringes of solder paste, which are stored in a refrigerator (we probably confused some people at Highland this summer…).

    The needles allow you to apply paste super precisely to the tiny pads of obnoxious SMT chips, but they often clog, so it’s good to keep extras on hand.

    Miscellaneous debugging tools

    Figure 13: Assorted jumper wires, a big electrolytic capacitor, a bag of grippy things, a binder clip, a ruler, and a Bus Pirate.

    • Jumper wires are just generally good to have around when debugging
    • Same goes for a decently sized capacitor. This particular capacitor (220 microfarads, 50V, aluminum electrolytic) helped me debug Tessel’s power input circuitry.
    • The grippy things are like small versions of those robot hands they sell at science museums, but for circuits; they’re used to grab onto unsuspecting wires, pins, or leads so that you can measure the voltage there. Lots of different tools come with these kinds of things, but these particular ones are made by Tektronix (one of the big test equipment manufacturers, and a company known for its analog oscilloscopes) and are designed to be used on SMT parts. In short, they’re the best grippy things I’ve come across with their long, skinny necks and super strong grip. There’s a reason I have so many of them.
    • Binder clips hold stuff, keep bags closed to keep moisture-sensitive parts dry, etc.
    • This ruler is open source! No, really. It also happens to have metric/imperial conversion charts, PCB spacing guidelines, hole sizes, and a whole slew of other useful information.
    • The Bus Pirate (and cable assembly) is a piece of OSHW that’s essentially the Rosetta Stone for communication with embedded devices. You tell it what you want to say and what protocol to use and it translates. Works with OSX and Linux and is available from Dangerous Prototypes (the creators) through Seeed Studio and SparkFun.


    Figure 14: Cardsharp, aka TSA bait

    This knife usually lives in my pocket, but bears mention because I truly bring it almost everywhere. The blade is good (medical-grade stainless which I keep sharp), but the handle is a little weird when you unfold it.

    Cables and boards

    USB Cables

    Figure 15: USB cables

    I have a bunch of USB cables. The ones in this picture are A to B and A to micro, and I use them to talk to an Arduino Uno and Tessels, respectively. The two in the little box are the same kind that our Beta backers get (whoo colors!).

    Arduinos and Tessel modules

    Figure 16: a handful of modules and an esoteric Arduino

    Tessel modules (RFID, Ambient, and GPS), an Arduino Pro Mini, and an FTDI USB to serial adapter + mini USB cable. This particular Arduino is great because, unlike the Uno and the Mega (which I have but don’t always carry with me), it’s a 3.3V device (so’s the Tessel). I use it to test and debug modules without worrying about breaking the module with a 5V signal. The downside to the device is that it needs the external USB to serial adapter in order to be programmed.

    Tessel (of course)

    Figure 17: my Tessel

    Last but not least, my Tessel (and yet another micro USB cable). This particular board has been hacked so that it uses an external antenna, and I’ve been using it to test the range at which Tessels can connect to WiFi. Perhaps “hacked” is a strong word: the current version of the board has the footprint for an MMCX connector (the smallest, most robust RF connector I know of) on it so that it’s easy to swap to a more sensitive antenna. Here I’ve attached an MMCX to SMA adapter from SparkFun to connect to a 2.4 GHz WiFi antenna.

    …And that just about does it. The old school EE in me feels compelled to also mention the concept of a good lab notebook (there are actually some interesting legal reasons here) in which you date every page and write only in pen…and that I almost always use a fountain pen. The rest of me would like to remind our readers that I am not, in fact, an old man.


    P.S. Even though studies overwhelmingly show that learning by doing is the best way to retain information, good whitepapers and lectures still have their place. Here’s a link to my personal stash of application notes and reference guides from a few of the big players in the electrical engineering space. The trove grows with time, and grows fastest when I’m building exciting new things. Enjoy!

    #tessel #technical machine #eric kolker #electrical engineering #hardware #hardware hacking #toolbox #tools

  • Monetizing Open Source

    Tuesday, November 19, 2013

    11/19/2013— Tim Ryan

    Free and Open Source Software helped shape the growth of software development. Giving users the freedom to modify and control their own devices, as well as contribute freely to their development, is uniquely possible in this industry. Even today’s fashionable litmus test for hiring (“Github is My Resume”) measures open source contributions as a proxy for developer skill.

    Open source is such a strong ideology that the first time someone asked “How are you going to make money off of open source?” I stuttered. The question they implied was, “Why are you developing a product and giving it away for free?” A quick reading of the freedoms that FOSS gives users seems to imply that making money is the antithesis of user freedom.

    Any research into what successful open source companies do will show you that, yes, most companies don’t “make money” off open source code—they make money through services, support, or selling products with an “open core”. So what is the business motivation for releasing any part of a project as open source or under a FOSS license?

    If you release free or open source code, you’re willfully revoking your legal monopoly to control how people modify or use your code—good for you! Whether you make your source code available for inspection/modification, or choose a license that lets users freely deploy that code to arbitrary devices, it’s a simple exchange: You are irrevocably trading copyright you own in exchange for other benefits.

    Consider developing a JavaScript interpreter. If your goal is compatibility, there is a massive amount of existing code in the wild, most of which you didn’t write (unless you’re substack). More likely than not, bugs will be found by your users, not you. If your interpreter is closed source, the majority of users will discover your bugs, and a relatively few number of developers will be responsible for fixing them. Meanwhile, the user who has the issue has more incentive than you (for a time) to see that bug fixed. To open source the code would trade your right to keep the source code private for the potential for outside developers to submit patches, broadening your code coverage as well as your development speed. If achieving broad compatibility is less important than licensing your code, the rationale checks out.

    Depending on your license, you may revoke your ability to charge money to license your code. A common solution is dual-licensing: release code under the viral GPL license and license it under a commercial license. Here, you revoke your right to keep code private, while directly selling to businesses the right for them to keep their code private. Hypocrisy! But also wildly successful, and demonstrably profitable. Not only are to targeting customers with a) money and b) incentive, you’ll also reaching to those to stand only to benefit from open source code by improving it.

    These days, many companies release code under the MIT/New BSD/Apache licenses, which essentially revokes a) the right to keep code private and b) to prevent users from building closed-source products on top of them. You might look at Heroku, Nodejitsu, and others as businesses that released their entire stack under these licenses. Always-on Internet connections have made service-based businesses possible, changing licensing from “charge for access” to “charge for time/resources”.

    (Interestingly, shared source—making source code available only to licensees—hasn’t seen much traction. Perhaps a solution you can debug but not alter yourself is no better than one you can reverse engineer.)

    Adapted from David A. Wheeler (2007)

    The hardest aspect of rationalizing “how you get paid with open source” is because when no money changes hands, you don’t. An open source project is not a business; it’s a trade of rights for increased development velocity, enthusiasm, or marketshare. You can build a business profiting off marketshare with ads, create powerful services around an open core, or build a profitable brand around enthusiastic supporters. Each of these benefits from open sourcing code, but is fundamentally a business in its own right. When you find business models that users are familiar with and which satisfy their needs, there is the potential to make money, not in spite of, but as a direct result of open source projects.

    Code costs nothing to distribute and benefits from more eyes, not fewer. If reserving your copyright doesn’t offer business value—or actively detract from your business—get rid of it! Open source or freely license your code, build a community around it, and strengthen your core business/brand/market—that’s what you’re making money on anyway, right?

    — Tim, software man

    #tessel #technical machine #tim ryan #open source #monetization #startup #company culture

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013