21.co has just done a major and somewhat bumpy upgrade to the beta version of its app marketplace The system went down during the day on Tuesday for the upgrade, which was announced as focusing on upgrade from IPv4 to IPv6, and rather surprisingly did not come back up until early Saturday morning. I say “surprisingly” because five days is an aeon in the era of continuous deployment. When I was at LexisNexis 20 years ago we did minor releases at 3 am with no more than an hour’s downtime and major releases on Saturday mornings with a huge team on site. A five day downtime would have gotten people fired. Even as a solo self-taught technical founder also running a beta service (PageKicker.com) I work really hard to keep downtimes as short as possible. If I had a 20+ person team and had a five day downtime, I would be in hysterics. I don’t want to be negative, I love 21, the people are super smart and I am sure they know a lot more about state of the art software management processes than I do and that they managed the deployment as well as humanly possible, but from an external point of view, this was odd.
To reality check myself a bit, I did some investigation of what’s required to transition from IPv4 to IPv6. It can be a big process: see this outline for enterprises from Cisco. (There’s a Cisco exec on the 21 board so good chance they’re using Cisco stuff…) Key takeaways: “A transition could take a few months or years, depending how aggressively your company and ISP move.” Ok, 21’s a startup, so let’s assume they’re going to move fast and break things. Five days is pretty darned good to do something that might take BigCo months. But note item 8: “Deploy incrementally and test. Initially deploy IPv6 in test environments (ideally in lab or pilot networks) that represent the devices and applications targeted for integration. Keep users informed, solicit their feedback, and analyze the operational metrics.” That didn’t really happen here.
Once the service came back up, I began by taking their guided tour of the new features.
The new features sound good: IPv6 support is a necessity for Internet of Things; persistent app URLs fill a crucial gap as they are essential for developers to market their apps; and secure routing through the 21 Hub sounds like an essential security fix. So, onward to explore the new marketplace!
Ruh-roh: “all existing apps must be updated.” That’s not good! I already have six apps and I will need to update all of them. Fortunately, there is an upgrade tutorial and it’s not too painful. In a nutshell, the syntax of port addresses must be changed to allow for IPv6, which only requires changing a single line in two files.
To make these simple upgrades, I need to leave the 21 network and rejoin on IPv6. But 21 has added a restriction that prevents my Ubuntu 16.04 laptop from joining the 21 market. I’m not totally out of luck, since I have an Amazon instance, but I’m inconvenienced, as I prefer to do my development on my laptop.
The look and feel of the marketplace itself has not changed much. It still uses floating cards for each app. (See how the second card is a bit displaced from the others below–it’s hovering!) I’m not overly enamored of this design–it feels like UI designers being too clever for their own good. It would work much, much better on a mobile device, which may be part of the thinking–it is mobile-friendly from the get-go. However, the current apps are intended for developers using keyboards, so it’s not really a good fit for now. Also, the search-centric interface will need to incorporate faceted search & display as the number of apps increases, and sorting “Latest APIs” by star rating instead of date is inaccurate and impedes discovery. Either the label should be changed to “Highest Rated” or sort by date and popularity options should be added. Displaying the apps this way is going to keep the Zip Code Data app at the top forever, because it’s always going to be most downloaded and therefore most rated. That’s not a bad outcome as a way of introducing new developers to the platform, but is a nuisance for those who might like to have their apps have a better chance at rising to prominence.
Persistent URLs to each app are available by the browser feature of hovering over the app “cards” in the marketplace. It would be nice (and better) to add permalink and social share buttons to the cards themselves. These are easy features to implement, and 21 already asks users to connect their social networks to their user accounts at 21.
I ran my 21 marketplace assessment tool (big talk for a simple-minded scraper) to gather some statistics about the app inventory in the new market. In a nutshell, nothing much has changed except that the number of available apps has been temporarily reduced by about half to around 50, and those from 21dotco only. An avoidable downtick in a KPI, but presumably this will swiftly be corrected as developers bring their apps into compliance.
So, to sum up, it looks like this release has two major infrastructure features and one minor interface improvement, coupled with some minor inconveniences for developers of current apps. The new infrastructure features aren’t much immediate benefit to the mostly little guy developers in the current Slack community, but they are necessities to help open up the “final frontier” of the vast scale of the 21 vision.
All in all, progress, but not, from the external perspective, super well executed. To be fair, the external perspective probably doesn’t, and shouldn’t, matter very much relative to the overall state of execution of the roadmap, which is probably characterized by a lot of stuff going on behind the scenes; 21 is still cloaked in quite a bit of stealth. Probably fair to say that the strategic communication could be handled a bit better. 21 has had some self-inflicted wounds in this area. When they released the 21 Bitcoin Computer last November, they were dinged by many members of the bitcoin community for releasing an “overpriced Raspberry Pi” because 21 was not able to get across that they were really serious that the 21 BTC was intended as an integrated hardware/software test platform. Admittedly, this was heavily influenced by the contentious and quick-on-the-trigger nature of the bitcoin community. But dings go into the overall picture, and if possible, should be avoided.
In future, major releases and downtimes should be faster and more transparent. There is really no excuse for not warning developers that a breaking change is coming. “A major upgrade coming this week will cause about a day’s downtime and your applications will be invisible until you make changes that will take about an hour per app to make and test. If you want to get started ahead of time, here are the instructions.” Also, it seems to me that it is a strategic communications best practice that major new features should be accompanied by concurrent publication of assessments and explainers from credible third parties.
In any event, onward! Stay tuned for future installments of Machine Payable Web News.