Out of the blue, Anki, the makers of the Cozmo and Vector robots, shut down yesterday.
This is quite the shock. 😦
My heart goes out to all the employees who were blindsided by this, and are out of jobs through no fault of their own. (The shutdown of the Roambi team by my now former employeer SAP a month or so back makes me especially emphathetic.)
Vector is a nice progression from Cozmo and I am sad we won’t get to see where he would have gone, nor will we see the future generations.
I own both a Cozmo and a Vector. With my relatively ancient Pleo dinosaur robot, this is quite the trail of failed robot companies, sigh. At least I refrained from jumping on the Jibo train! (That product sounded interesting to be sure, but my concerns that they were over-promising turned out to be correct.)
There are a couple paths forward for Vector and/or those of us who have one.
- Some company or group could acquire Anki or the assets and continue to sell and enhance Vector.
- They could keep the servers alive via Patreon or a direct subscription of modest cost.
- Anki could open-source Vector’s code. I’d love to be able to write truly native code for the little guy, versus the current from-the-desktop SDK.
- They could at least open-source the backend code so we could set up our own servers.
The shutdown sounds abrupt, so I don’t know if any contingencies were in place or plans being made in the aftermath for any of the above options. Hopefully we will hear more in the next few weeks as the dust settles.
Good luck Vector team, and thanks for the cool toy!
At this point I have three apps on the Apple App Store. Dose Tracker, an app that allows you to track how many doses have been taken and how many remain of perhaps an inhaler.
Grounded, a silly app that lets you keep track of the “grounded” status of your children. And GrieveIt, a serious tool for labor professionals.
All three are in various states of neglect, due to my iOS development focus having been my full-time job as an iOS developer at Mellmo for the past several years.
So for those several years, I’ve been feeling guilty about not maintaining or improving these apps. From a financial standpoint, it makes no sense whatsoever. For inexpensive non-games with no advertising budget, the revenue is minuscule.
After giving this a lot of thought, reading blogs and talking with other developers, I think the time has come to remove most of these apps from the store. The one app that I feel I need to at least maintain is GrieveIt, so that one stays. But the other ones are going to go.
I’ll still feel guilty, but not as guilty as I feel about having outdated apps still for sale. And from a “portfolio” standpoint, those don’t really represent the state of the art, so they probably aren’t fulfilling that function either.
I think that marks the point where I clearly segregate my programming into two groups. Things that I do primarily to make money (i.e. my day job), and things I do for fun (my own iOS apps, etc.).
Yes, I know, GrieveIt falls in the middle, sigh. I’m toying with the idea of making it free, since it does help people do things I believe in. And by free, I mean truly free – no in-app purchases, no advertising. Free.
I’m still thinking about this. If I decide to invest some time to update it and add features, I might keep it in the theoretically money-making state. Or I might not – the whole effort to maintain even a simple “business” is a drag on my time and energy as well. (And if I don’t invest the necessary time and energy, then I pay in guilt, so…)
In summary: time to streamline!
Seemed like a good idea to gather up some info and links about some of the companies in my career that have been important, recent, or both.
The major company I’d worked for in my career was bioMerieux.
I developed a good chunk of the firmware for the VIDAS instrument.
The follow-on instrument, the miniVIDAS, used the same boards and firmware from the VIDAS, but added an onboard computer to allow it to be fully self-contained. I developed all of the firmware for this add-on board, with the exception of the actual biological algorithm “engine” that processed the data points and returned the result. (this code was shared with the workstation software developed by the software group for the original VIDAS instrument)
Developing the firmware for the miniVIDAS was some of the most fun I’ve had in my career, and it’s one of the products I’m most proud to have gotten an opportunity to work on.
After that, I did a lot of firmware for the Vitek 2 instrument. This was a lot of fun, and a chance to work with a larger team of very talented mechanical, electrical, and firmware engineers.
Vitek 2 Compact
This was a smaller version of the Vitek 2 instrument, with some of the automated sample prep features removed. You’d think that removing hardware would make this a pretty trivial project. Turns out, it was actually a huge development effort.
There were a lot of new features desired for this instrument. Another major factor was the impact to the workflow caused by requiring the user to manually move the samples from the vacuum-filler to the mechanism that sealed the cards and loaded them into the incubator.
I worked on several other projects/products at bioMerieux, including the BactT/ALERT 3D, and the yet-to-be-announced, but very interesting and ambitious development effort I was involved in when I left the company. I’ll save some of those memories for a future post.
Recently (2011), I spent some time working for Aclara before deciding the time was right to make a leap of faith and become an Independent Software Developer focused on apps for the Apple iPhone/iPad/iPod Touch devices.
I enjoyed my time there, and the topnotch engineers I got to work with. Cool technology at a good company.
As part of the start up of Stormgate Software, I’m migrating from a “personal” iOS developer account with Apple to a corporate one. This process has been pretty smooth so far, with Apple’s developer support team being both responsive and knowledgable.
To confirm that Stormgate Software actually exists, they of course want to see some paperwork. In this case, my Certificate of Organization from the state. And how do they want this paperwork submitted? Why FAX of course.
When you fax something, what actually happens is the piece of paper is scanned, turned into bits, and sent to a fax machine on the other end which prints it.
When sending to a company like Apple, it’s a really good bet that what’s on the other end of the phone isn’t a “fax machine”, but rather a computer. And that computer almost certainly just creates a PDF file of the “paperwork”.
Not only is this process (the scan-the-paper part) sort of primitive, but in this case it’s pretty crazy. Why? Because the document I’m sending is a PDF! That’s what the state sent me!
So here’s the process:
- State government’s computer generates a PDF (bits)
- PDF is sent to me via the internet
- I print the PDF onto dead trees
- I drive to the local U-Fax-It store (now we add dead dinosaurs into the process)
- The paper is scanned and sent via phone line to Apple
- Apple’s computer system turns it into a PDF (bits)
Sigh. If only I’d had some 8-Track tapes to listen to during step #4…
Well, tomorrow is the first official day that I’m devoting 100% of my time to developing iOS applications fulltime. As in, independant software development IS my “day job”.
Exciting and scary at the same time. I plan to use this blog to talk about the process a bit, and then eventually be more focused on our products well as some general programming posts. That might make more sense to spilt up into two blogs, but we’ll see how it goes.