Back on the ASF board

Today I was re-elected to serve on the Board of Directors of the Apache Software Foundation. This will be my third term on the board. I served the 2012 term, sat out the 2013 term, and then served the 2014 term.

This year, in addition to most of the sitting directors being returned to the board, Shane Curcuru and David Nalley will be on the board. Shane has been on the board before, but I’ve never been on the board with him at the same time. And this will be David’s first term on the board.

It’s a big honor, as well as a considerable responsibility, serving on the board. While we (intentionally) move slowly at the ASF, there are still big issues to be considered. And there’s the health of our 160+ projects to watch over, giving a nudge here and there when things start to go off the rails.

At today’s meeting, we also elected a large number of new members to the Foundation. I can’t tell you who they are, yet, as they need to accept their invitation first, and some folks don’t. But we’re excited to see such a great list of new members being invited, and anxious to hear their new ideas on where the Foundation will go in the years to come.

 

Spinning your straw into gold

Spinning your straw into gold
For E

Emerging from under the haystack
halo of straw around your head
the night under Claude Monet’s hayrick
and the dreams still
caught in your hair

You squirm like Rumpelstiltskin
stamping your feet and shouting
as we chase the rats back into their holes
tease out the tangles
find the treasure in the brambles
spin your straw into gold

Wheatstacks_(End_of_Summer),_1890-91_(190_Kb);_Oil_on_canvas,_60_x_100_cm_(23_5-8_x_39_3-8_in),_The_Art_Institute_of_Chicago

90-9-1

1 Comment

In a talk I attended earlier this year, Shaun McCance mentioned, as though it was established science (which it is) the 90-9-1 principle of community participation. I’ve thought of it frequently since then, to set expectations and to keep myself sane.

The idea is that in any community effort, 90% of the people are going to sit around saying that it’s a great idea, but not actually doing anything about it. 9% of the people are going to work casually on it in their spare time, as convenient, and between them will do a huge amount of the work. Then 1% of the people – usually one or two dedicated people – will pour themselves into it wholeheartedly, putting every spare moment into making it a success.

Note that it’s not the exact numbers that matter here, it’s the undeniable fact that you can’t expect everybody to work as hard as you do on everything. It’s all too easy, when doing anything on a volunteer basis, to look around and get frustrated, discouraged, even angry, at the 90%. Understanding that this is the normal, expected, even healthy way that communities operate, can help you refocus on what you can (and can’t) do in any given effort.

Sometimes (most of the time) it’s ok to be in that 90%, and you don’t need to feel that you’re not pulling your weight. However, if you’re in the 9% or the 1%, it’s not reasonable to get angry with the 90%. They have other things to do, and are likely the 1% on something that you’re not helping much with.

By the way, here’s a couple of resources about this notion:

This article claims that the concept is dead. Note that this article appears to be someone just making up new numbers to illustrate the same concept. What’s important here, folks, isn’t the exact numbers, but the general concept. Way to miss the point. (This article also appears on dozens of sites in various different forms.)

Wikipedia claims that it’s a feature of Internet culture.

Here’s an actual statistician doing scientific analysis, rather than me making up numbers.

ApacheCon Budapest 2014

1 Comment

15811606055_5637e3d709_zLast week, the Apache Software Foundation, with the help of the Linux Foundation event team, hosted ApacheCon Europe in lovely Budapest, Hungary at the gorgeous Corinthia hotel.

If my count is right, this was the 24th event to bear the name ‘ApacheCon’, and the 8th time we’ve done it in Europe. Also, we were celebrating the 15th anniversary of the Apache Software Foundation, which incorporated in June of 1999.

Every ApacheCon has its own set of memories, from Douglas Adams pacing the stage in London, to the ApacheCon Jam Sessions in Dublin, to the Segway tours in San Diego, to the funeral march in New Orleans. And Budapest was no different – a wonderful event with lots of great memories.

On Sunday night, I had dinner with the TAC’ers. The Apache Travel Assistance Committee is a program by which we get people to ApacheCon who could otherwise not afford to be there. This is critical to the mission of the ASF, because it builds the community in an inclusive way, rather than limiting it to people with the funds to travel. TAC recipients have to give back a little – they provide session chair services, introducing speaker and counting attendees. A large percentage of our former TAC recipients have become deeply involved in the ASF, more than paying off the investment we make in them.

Although I didn’t try the Tripe And Trotters on the buffet line, I did enjoy great conversation with old friends and new ones around the table.

15813169492_0cd44f034e_z

Monday morning, I opened the conference with the State Of The Feather keynote – our annual report on what the ASF has done with sponsor dollars and volunteer time over the last year, and some thoughts about where we’re going in the next 15 years. The latter is, of course, very difficult in an organization like the ASF, where projects, not the Foundation leadership, make all of the technical decisions. However, David Nalley, the VP of Infrastructure, had some pretty specific ideas of what we have to do in terms of Infrastructure investment to ensure that we’re still able to support those projects, which are being added at about 1.5 a month, for the next 15 years and beyond.

15820067232_75991115c0_zAfter the State of the Feather, I had the enormous privilege to stay on the stage with Hugh Howey to discuss the parallels between self publishing and open source software development. I’ve got another blog post in the works specifically about that, so stay tuned, and I’ll add a link here when it’s ready. Any day that starts with me hanging out on stage with a favorite author in front of 300 of my closest friend is a good day.

Once the sessions started, everyone went their separate ways, and I gave several talks about the Apache httpd project. httpd has been my main focus at Apache for 15 years, and although it’s faded into the background behind more exciting projects like Spark, Hadoop, CloudStack, Solr, and so on, it’s still the workhorse that powers more than half of the websites you’ll ever see, so there’s always a decent audience that turns out to these talks, which is very gratifying.

One of my talks was more focused on the business of doing documentation and “customer support” in the open source world. My “RTFM? Write a better FM!” talk discusses the RTFM attitude that exists in so many open source software communities, and how destructive it to the long term health of the projects. I’ve got another blog post in the works specifically about that, too, and I’ll add a link here when it’s ready.

Tuesday and Wednesday were a whirlwind of sessions, meetings – both formal and informal, and meals with friends, colleagues, and newly-met conference attendees. As a board member, I’d sometimes get pulled into project community discussions to offer the board’s perspective on things. As conference chair, there we numerous discussions about the upcoming event – Austin, Texas, April 13-17 – and the next Europe event – stay tuned, announcement coming soon!

Session highlights during the week include:

  • Shane Curcuru’s talks on trademarks, copyrights, and protecting the Apache brand.
  • Jesus Barahona’s talk about the statistical analysis work he’s done for Cloudstack, and other projects, and how it can be used to support and encourage community growth.
  • Pierre Smits’ case study talk about OFBiz and beer, which I missed because I was speaking at the time, but which I heard was amazing.
  • Joe Brockmeier’s talk about Docker, which was apparently the best-attended talk of the entire event.

Although we didn’t record the talks this year (if you’re interested in sponsoring that for next time, get in touch – rbowen@apache.org), you can see the slides for most of these talks on the conference website.

15816582111_4b19b886c5_zOn Monday night we had a birthday cake for the ASF, and I got all emotional about it. The ASF has been hugely influential in so many aspects of my life, from my amazing friends to my amazing job, and it’s such an honor to serve the Foundation in the capacity of conference chair. I look forward to the next 15 years and seeing where we go.

And then, so fast, it was Wednesday evening. David Nalley gave his keynote about the value of the Apache Software Foundation. While I was expecting a number – something like 3 trillion dollars or something – instead, he talked about the many ways that the ASF adds value to companies, to individuals, and to the world as a whole. A truly inspiring talk, and it made me incredibly proud to be associated with the ASF. Bror Salmelin then talked about the Open Innovation 2.0 project at the European Commission to close out the formal portion of our event.

The lightning talks were a big hit this time around, with a great mix of serious and lighthearted talks, all in five minutes or less, MC’ed by the inimitable Joe Brockmeier.

15647039319_0624e084ce_z

On the whole, I was very pleased with this conference. If there’s anything that disappointed me about the conference, it’s only the number of old friends who couldn’t make it. I hope that everyone who couldn’t make it to Budapest is able to come to Austin to celebrate the 25th ApacheCon, and the 20th anniversary of the first release of the Apache HTTP Server!

 

[Note: Some of these photos are mine, and are on Flickr. Some of them are from the Linux Foundation, and are also on Flickr.]

We’ve Always Done It That Way

From a Lightning Talk at ApacheCon Budapest

As you know, the Apache Software Foundation has a number of mottos that we like to use. Like, “Community Over Code”, and “No Jerks Allowed.” Another popular motto recently has been “We’ve Always Done It That Way.”

As you no doubt know, the ASF is an organization deeply rooted in tradition, which means that we never, ever change the way that we do anything. Those of you who have been around the ASF for a long time can verify this.

Here’s a few of the things that have been the same at the ASF for all time.

We have always required that every project have their code in CVS for revision control.

Um … I mean SVN. As far back as we’ve been around. We’ve always done it that way.

Well, except for … you know … unless your code is in Git.

But we definitely don’t let you use Github for collaboration.

… actually …

You Infrastructure guys ruin everything.

Since the beginning of time, ApacheCon has been organized and produced by a committee of members. We gather before the event, with all of the talk proposals printed out. We sort them into piles and argue over which ones will be scheduled. Third-party producers really don’t understand us, and so it’s important that we control every aspect of how ApacheCon is put together.

We’ve always done it that way. And so we’d never try anything else.

We have never had any paid staff, and would never consider having any.

All ASF projects are written in C, and always have been.

Also, all projects at the ASF are server projects of some kind. Desktop-type software projects are completely outside of what we do – what we’ve always done.

Wikis are the spawn of Satan, as we determined on long, heated, vitriolic mailing list threads, and we’ll never allow any project to have a wiki. At least, not one running on ASF hardware. Ever.

Except … these things have all changed.

Principle 13 in the Toyota Way says that one should make decisions slowly, by consensus, thoroughly considering all options, and then implement those decisions rapidly. We believe a similar thing at the ASF. So to people who have only been around for a short time, it looks like we never change anything. But the truth is that we change things slowly, because what we’re doing works, and we need to be sure that change is warranted, and is a good idea.

There is one thing, though, that I’m sure won’t ever change. Here at the ASF, we believe in collaborative, community-centric development.

We’ve always done it that way.

ApacheCon North America returns to Austin

We just got done with ApacheCon Europe in Budapest last week – http://apachecon.eu/ – and it’s time to start thinking about ApacheCon North America.

We’ll be holding ApacheCon North America, April 13-17th, 2015, in Austin, Texas. The call for papers is already open, at http://apachecon.com/, and we are hoping that this event will represent the breadth of the Apache Software Foundation projects.

Organize your community

The most important thing at this stage in the process is getting the Apache community involved in this event. ApacheCon exists to unite our community, get various projects to interact with one another, and bring new members into our community. The best way to accomplish these goals is to ensure that your project has representation at ApacheCon. Here are four specific areas where we need the help of Apache project communities:

Track layout

We’ve found that the very best way to have a project well represented in the content tracks is for someone deeply familiar with the project to craft an ideal track schedule, and then solicit speakers for those sessions. This has two immediate benefits.

First, it goes a long way to ensuring that the topic is covered with the breadth that it deserves, rather than having a few random talks that cover random esoteric parts of the technology, and ignore segments of the audience that you most want to attract.

Second, it is very encouraging to first-time speakers. It’s very difficult, and very intimidating, to try to come up with a topic to speak about the first few times. Seeing a list of proposed topics is the perfect way to say to a new speaker that what they know about is worth them proposing to a conference. “Hey, I could speak about that, and nobody would think it’s a stupid idea.”

Speakers

Some talks require certain speakers. You know this a lot better than we do, because it’s your project. We need your help to go to those specific speakers and encourage them to submit the specific talk(s) that you know they’ll shine at.

Reviewing and Scheduling

Once the talks have been submitted, we’re going to need your help reviewing them and building the schedule. To help with the review process, you’ll need to create an account in the CFP system (if you haven’t already done so) at https://identity.linuxfoundation.org/user and then email me – rbowen@apache.org – with your username, so that I can get you added to the review system. From there, you’ll see a list of talks to consider, and you can rate them according to how well you think they’ll fit the conference.

Of course, if you specifically solicited those talks, then you’ll quickly mark them as “Strongly Accept” with a comment of “I solicited this specific talk”, and move on. (The CFP review interface is at http://events.linuxfoundation.org/cfp/cfp-list if you already have an account.) You can review talks from other topics/tracks, too, if you feel that you have some domain knowledge.

Once the review process is complete, we’ll select the talks that rate the highest, and at that point we’ll be back in touch with you to help us order them correctly. Here, again, if you’ve already approached us with a layout of your ideal content track, there’s really nothing else to do. But if there are other talks that made it in through the review process, we’ll need help.

Hackathons

A key benefit of ApacheCon is getting your developers together in one place to work on things. We’ve got a a general hackathon area where you can gather to work on bugs, features, documentation, or discuss thorny community issues. (Don’t forget to summarize your conversations back to the mailing list for the people who can’t make it!)

If you want to have a sponsored hackathon specifically for your project, we can find room to make that happen. Just get in touch with me, and we’ll work out the details.

Talking before the event about what you’ll be working on has a number of benefits.

First, it gives people time to think about how they can contribute, and plan accordingly.

Second, it encourages people to come in from the edges of the project to participate more fully in the life of the community, because they can select something that they’re particularly interested in, and work on it in company with the rest of the project members.

Using the ApacheCon wiki – http://wiki.apache.org/apachecon/ – as a place to work on your hackathon topics gives conference attendees an easy way to find topics that they might be interested in, and connecting with the community. If you don’t have write permissions to the wiki, send me your wiki username, and I’ll get you added to the access list.

Your company uses Apache software every day. Perhaps you even contribute to a project as part of your day job. ApacheCon is the best place in the world for your company to show off their involvement in Apache, and to find new talent to work on their products. Sponsorship of ApacheCon gives you a platform from which to talk about what your company does, and gets your company name recognized – and closely associated with Apache – by the people that make the decisions in some of the most important places in IT.

If you’d like to sponsor ApacheCon, get in touch with me, and I’ll get you a sponsor prospectus, and help you select the sponsorship opportunity that’s right for you – whether that’s the conference lanyard, an evening reception, the conference bags or tshirts, or a booth in the exhibit hall. There’s something for every budget and level of exposure you’re looking for.

Get the word out

You have the ear of your project community – both the developers and the end users. We need your help telling them about this event. Right now, we need you to tell them to save the date. Later on, we’ll need you to be telling them about specific talks that will be of interest to them, both directly relating to your project and about other related projects that they should know about.

Join the Community Development mailing list – http://www.apache.org/foundation/mailinglists.html#foundation-community – where we’ll be posting suggested tweets, suggested things to share on Facebook and Google Plus, and other suggestions for helping us get the message to the communities where you have a more trusted voice than we do.

This is critical – it does no good putting together a great event, if nobody comes. You know who needs to hear the message, and you know where they hang out. A well-placed message by the trusted members of the community is far more effective than a dozen mass emails from a stranger.

Come join us!

So, if you’d like to help us make ApacheCon a success, get onto the Community Development list – http://www.apache.org/foundation/mailinglists.html#foundation-community – and on the #apachecon IRC channel on Freenode, and speak up. Tell us what you can do, and we’ll find a place for you to fit in.

Keep bailing

There’s been a lot of talk in recent months about the appalling gender inequality, and discrimination, in the technology world. As a privileged white american male, I am, of course one of the beneficiaries of that inequality, as well as being part of the problem. I’m  very much aware of this, and am, most of the time utterly at a loss as to what I can do about it.

The thing that I find to do most frequently is to stand up and speak out against injustice when I see it. The term for this is usually ally.

However, as an ally, something that one tends to hear frequently is “do you think nobody has tried that before?!” The point here being that the thing that I’m doing hasn’t solved the problem yet, and am I so arrogant that I think I’m going to solve the problem myself overnight by trying what others have already done.

When I hear this, there’s two things that come to mind.

One is an image of being in a boat that is full of water, and having only a leaky bucket in my hands, I start bailing. Other people in the boat stare incredulously, and say, “do you think that nobody has tried that before?!” I have a choice here – I can yell at them for being obtuse. I can give up, quit bailing, and abandon ship. Or I can quietly keep bailing, in the full knowledge that I can’t fix everything, but I can help just a little. And keep bailing as long as I’m able, even if it doesn’t seem to be helping a whole lot. Because it’s not about me.

The other is my parents, who taught me to do the right thing, even if nobody notices, even if nobody cares, even if people tell me it’s a waste of time, or call me a fool for doing it – still do the right thing. Or, as Kent Kieth wrote (often wrongly attributed to Mother Teresa, according to motherteresa.org)

People are often unreasonable, illogical, and self-centered; Forgive them anyway. If you are kind, People may accuse you of selfish, ulterior motives; Be kind anyway. If you are successful, you will win some false friends and some true enemies; Succeed anyway. If you are honest and frank, People may cheat you; Be honest and frank anyway. What you spend years building, someone could destroy overnight; Build anyway. If you find serenity and happiness, They may be jealous; Be happy anyway. The good you do today, people will often forget tomorrow; Do good anyway. Give the world the best you have, and it may never be enough; Give the world the best you’ve got anyway.

The important corollary here is that if you do good, be sure you are clear, in your own mind, why you’re doing it. If you’re doing it so that people will notice you and thing well of you, you probably shouldn’t bother, because they won’t.

Paul Biondich keynote, LinuxCon Europe 2014

In his keynote yesterday, Paul Biondich mentioned a few numbers – OpenMRS has been in development since 2008, and is deployed in over 70 countries – but mostly, the number he focused on was one – individuals whose lives have been touched by the project. Doctors, patients, and Open Source developers.

I’ve been following OpenMRS for several years, since discovering the project while I was working at SourceForge, and learning that it was started by a visit to Kenya, to a hospital where paper-only medical records were hampering patient care. The trip, which Paul almost declined to go on, changed his life and the course of his career, and he began to devote his time to developing OpenMRS, which is now the standard medical records system in many countries, including Kenya.

Paul observed that medicine is, in large part, an information science. Having access to the right information at the right time can be the difference between the life and death of a patient. Of course, it’s only one tool in the toolbox, but it’s a critical one.

Paul, and all the other people at OpenMRS, have long been an inspiration to me, and represent all that is good and noble about Open Source. His keynote is well worth watching once the videos are posted.

 

What’s new in OpenStack Juno

Originally posted on opensource.com.

OpenStack is on a six-month release cycle, with each release given  a code name starting with consecutive letters of the alphabet. On October 16th, OpenStack Juno will be released, with several new projects, and lots of new features.

Here’s a few of the things you can expect in the next release of
OpenStack. This isn’t intended to be comprehensive – just a taste of
some of the things that are coming.

Nova

As the core of OpenStack, Nova needs to be solid. But this doesn’t mean that it’s slow to change, with some significant changes coming in Juno.

* NFV

NFV – Network Function Virtualization – is a big deal lately, and you
can look to see lots of people working on it, as well as vendors talking about it.

* Live Upgrades

First introduced in Icehouse, live upgrades were still a little rocky.
You’ll see big improvements in this area in Juno.

* More

See more of what’s coming in Juno in Russell Bryant’s blog post at
http://blog.russellbryant.net/2014/07/07/juno-preview-for-openstack-compute-nova/

Ceilometer

Ceilometer is the metering/measurement component of OpenStack.

* Speed

Over the last few cycles, the Ceilometer team have identified some
poorly-designed parts of the project, and have taken a lot of time this cycle to pay down the technical debt to regain some of the performance lost to those decisions. So you can look for Ceilometer to be much more efficient, and faster, in Juno.

* Community reboot

The project management is moving from a top-down decision making process to a collaborative community decision making process, so that everyone has a voice in how decisions are being made.

Additionally, some controls are being put in place regarding the code freeze at the end of the cycle, so that people aren’t trying to rush new functionality in at the last minute, resulting in testing gaps.

* QA

Speaking of testing, there’s also an effort to ensure more Tempest and Grenade test coverage in Juno, which should ensure better code
reliability.

* More

See more of what’s coming in Juno in this interview with Eoghan Glynn of the Ceilometer community:
http://community.redhat.com/blog/2014/07/upstream-podcast-episode-10-rich-bowen-with-eoghan-glynn-on-openstack-juno/

Heat

Heat is the orchestration component of OpenStack, which can be used to set up and tear down infrastructure automatically in response to environmental events, or scripted.

* Rollback

In the past, if a Heat deploy failed, you just moved on, and maybe went back and cleaned up by hand. In Juno, it will be easier to roll back a failed deployment, and be sure that all of the various pieces have been cleaned up.

* Create resources without being admin

In Icehouse and earlier, certain types of resources could only be
created as admin. In Juno, creating users will still require that you be
admin, but you can then delegate privileges to that user so that they
can create resources without having to be admin.

* More

Read more about what’s coming in Juno for Heat at
http://www.zerobanana.com/archive/2014/07/10#heat-juno-update

Glance

Glance is “a service where users can upload and discover data assets
that are meant to be used with other services, like images for Nova
and templates for Heat.” This is a new mission statement in Juno, and some of the changes that are coming are:

* Artifacts

The scope is expanding in Juno to be more than just an image registry, to being a generic catalog of various data assets. This will allow for greater flexibility in how it can be used.

* More

Read more about what’s coming in Juno for Glance at
http://blog.flaper87.com/post/juno-preview-glance-marconi/

Marconi

Marconi (Now renamed to Zaqar) is OpenStack’s messaging and queuing system, and so is very important to all of the other components.

* Redis

In Juno, Zaqar will add a storage driver to support redis, and
support for storage engines is in the works. It will be possible to create and tag clusters of storage and then use them based on their capabilities.

* Queues migration

The Zaqar team will be adding support for queues migration between pools of the same type. Read more at
https://blueprints.launchpad.net/marconi/+spec/queue-migration

* More

Flavio’s article at
http://blog.flaper87.com/post/juno-preview-glance-marconi/ also covers Zaqar, as well as Glance.

Keystone

Keystone is the identity management piece of OpenStack, and has some big improvements coming in Juno.

* LDAP integration

Using Keystone against a database is ok, in that it does password
authentication. But what you really want is to integrate it with your
existing user authentication infrastructure. This often means LDAP. In Juno, you can configure Keystone to use multiple identity backends, and integration with LDAP will be much easier.

* Other security projects

The same community that works on Keystone is also very interested in other security related projects in the OpenStack ecosystem. Look for projects Barbican and Kite to be more active in the coming months.

* More

Nathan Kinder’s article at
http://redhatstackblog.redhat.com/2014/08/05/juno-updates-security/ covers more of what’s coming in Juno. See also this blog post: https://blog-nkinder.rhcloud.com/?p=130 for clarification of some of these goals.

TripleO

TripleO is a project about installing, upgrading, and operating
OpenStack clouds in an automated fashion. This is a big area of interest in Juno – making OpenStack easier to deploy and manage.

* High Availability

A big push in Juno is deploying HA clouds with TripleO. This will be the default behavior, which has the added benefit of getting everyone testing HA deployments, even on “clusters” as small as 1 node.

* Heat templates

TripleO uses Heat as part of the automation of deployment. So in Juno a lot of work has gone into the Heat templates that are used.

* More

Read more about what’s coming in Juno for TripleO in James Slagle’s blog post at http://blog-slagle.rhcloud.com/?p=235

Horizon

Horizon is the web admin interface for OpenStack. While many people will interact with OpenStack via the command line and APIs, the web interface is still the face of OpenStack for many OpenStack operators.

* Sahara (Hadoop)

Sahara is a new project that makes it easier to deploy Apache Hadoop or Apache Spark on OpenStack. This project has graduated, and so it’s now integrated into the dashboard, so you can deploy Hadoop clusters with a few mouse clicks.

* JavaScript unbundling

As good Open Source citizens, Horizon has moved to unbundling the
Javascript libraries that were previously copied into the Horizon source tree. This not only makes it easier to manage upgrades, but also complies with no-bundling requirements in certain Linux distros like

* More

See more about what the Horizon team is doing for Juno in Matthias
Runge’s blog post at http://www.matthias-runge.de/2014/09/08/horizon-juno-cycle-features/

See also

This is just a sampling of what’s coming in Juno. As well as reading all
of the excellent articles at https://openstack.redhat.com/Juno_previews
see also the YouTube playlist of PTL (Project Technical Lead) webinars.

And come to the OpenStack Summit in Paris to see what we’ll do for an encore in Kilo.

Sensordrone

I’ve been reading some things about Sensordrone – the first commercially available functional Tricorder … sort of.

photo-full

It’s a multi-sensor device that communicates with your phone via bluetooth, providing a variety of environmental sensor information – temperature, humidity, lighting. presence of various gases, and so on.

It looks like the kind of thing that would be ideal for home automation or other “internet of things” automation.

Unfortunately, it’s at a price point – $200 – where I have to seriously consider what I’d actually do with it, which is, probably, not a whole lot.

What will be cool is when these kinds of sensors are so cheap to make that they’re in everything. Remember 10 years or so ago, GPS technology was still crazy expensive and now there’s a GPS chip in everything from your camera to your phone to your watch.

The Margin Is Too Narrow