This week I’ve been up at QNX HQ in planning meetings. This was a great experience for a number of reasons, but, primarily just seeing the QNX leadership team in action. I’m a guy who bears the scars of product review meetings with Bill Gates over the years, so, when people say technology isn’t a contact sport I beg to differ. I have to say what I saw this week was very close to sessions I remember from Microsoft at it’s peak in the 1990’s. The good news, seeing the emphasis on architecture.
BGR reports that iPhone is more vulnerable than Android and Windows Phone and BlackBerry, snippet follows:
A new report suggests that Apple’s (AAPL) iPhone is more “vulnerable” to attacks than Android, Windows Phone and BlackBerry (BBRY) smartphones. According to a study from SourceFire, the vast majority of all mobile phone vulnerabilities that have been discovered so far have been found in Apple’s smartphones. The firm found 210 vulnerabilities in the iPhone, giving iOS an 81% share of known mobile phone vulnerabilities, while Android, Windows Phone and BlackBerry devices combined to have a 19% market share.
Yves Younan, a senior research engineer at SourceFire’s Vulnerabilities Research Team and author of the report, revealed to ZDNet that the results were “surprising.” He added that it was also “interesting” because Apple has continued to implement additional security features in new versions of iOS.
I’m not sure why this should be surprising to anyone, any platform that hits a sufficiently large number of users will fall prey to attack. The many lessons that we learned on the PC platform are happening, albeit at an accelerated pace, on the smartphone platforms. This is something that we all have a stake in and every business and consumer smartphone customer will need to be responsible for “securing their end point device”, i.e. your phone, just like you have secured your PC. No platform is truly immune, active measures are called for.
At BlackBerry we’ve built in several features to help, BlackBerry 10 has built in support for our Fusion MDM product to remotely manage and more importantly to remotely wipe sensitive corporate data. We’ve got Balance, essentially separate “personal” and “business” partitions built into the platform keeping work and personal data and apps separate and secured. Our BlackBerry World store has “Enterprise Store” capability, allowing businesses to select, manage and distribute only the applications they’ve approved on the business partition. Finally, we’ve also announced our relationship with Trend Micro to keep our BlackBerry World stores malware free.
I wish that it were the case that all the features and services we’ve built for BlackBerry 10 were enough, however, you’ll need to take additional steps to insure your apps, services and phones are secure for your customers and employees to the best of your abilities. This includes preparation, education and implementing sound policies and procedures. This is our shared responsibility in the smartphone ecosystem.
Hal Berenson, former Microsoft Distinguished Engineer, writes an amazing blog about his insights into past and present goings on at our former employer, but in this post he drills into what’s gone wrong with Windows 8 and Windows Phone 8 evangelism. I have to say, I totally agree with Hal, the WP8 evangelism approach of Apple-like secrecy was plain wrong, and ignored all the hard won lessons of the MS Evangelism Playbook.
As one of Microsoft’s original Evangelists and co-originators of the PDC and founder of WinHEC, the former Windows software and hardware ecosystem conferences now defunct, sharing as much technical information as early as we could was instrumental to building support for each release of Windows I worked on. I talked about this in an earlier post, how evangelizing products early paid off for Microsoft and now BlackBerry. Hal focuses on the feedback angle, realize at Microsoft we had smaller and NDA only feedback sessions sometimes years in advance of the PDC to fully brief and gather feedback from the ISV community. These were the little known Microsoft Systems Design Review series and more granular feature level design reviews we convened with key technical leaders in the industry.
At BlackBerry being open and working with the app development community early as possible has already paid dividends for BlackBerry 10 with record early support. We see no reason to change our approach, if the rest of the industry continues down the secrecy path, so be it. I’m happy to run this key tool from the old evangelism playbook, time tested with proven efficacy.
Something that I started at Microsoft was Hardware Ecosystem Managment, well, I always called it Hardware Evangelism. Immediately following Windows 3.11 shipping, Microsoft recognized that PC’s at the time were too hard to configure. A lot of people reading this post won’t have the faintest clue of what I’m talking about when I say you used to have to know about IRQ’s, DMA addresses and jumpers. For the folks from the UK I’m not talking about sweaters. I’m talking about all these things you needed to configure to add a new card to your PC, or connect a printer or attempt to add a new hard disk to your system. All these things were monstrously hard to do before Windows 95, USB and Bluetooth weren’t even things I could even have fantasized about.
So, what about applying Evangelism to…. hardware? Well, many of the same principles applied. Remember, there are things called device drivers that have to be written. Firmware in ROMs need to be written to support new chipset features. Protocols need to be understood by each subsystem of the operating system to discover, enable and configure new hardware devices. So what did we do at Microsoft? Well of course we created a conference, I of course creatively named it the “Windows Hardware Engineering Confernence” or as it became known in the industry, WinHEC. We distributed Device Driver Development Kits, or DDKs. We worked with standards bodies, industry groups, chip makers like Intel, companies who made motherboards,BIOS makers, third party chip set makers, display card vendors, harddrive vendors, the list goes on….
So all this information was published in a book called the “Hardware Design Guide for Windows ’95”, a description of all the new protocols, subsystems, interfaces and signaling that the Windows 95 kernel made available to implement the first implementation of Plug and Play on the PC. This is what you know today, in most cases you just plug something into the PC and it just works, er, most of the time. This book described the operating systems requirements to the PC hardware ecosystem to allow their devices to fully participate in Plug and Play.
To test these new Plug and Play devices with Windows our team hosted innumerable “Plug a thons” and for some devices “Connect a thons”, to be honest, after all these years I can’t remember what was different about the two events. We created a new Logo Program and the “Windows Hardware Quality Lab” that managed the logo program and outside testing firms to certify both the new device drivers and the new hardware so consumers could easily identify Plug and Play enabled devices and PCs.
We even worked with the standalone chip foundries to insure runs of specialized chips were in the supply chain.
So why am I bringing this up? Today many new startups are building devices that either interface to mobile devices via Bluetooth or WiFi, and solutions we pioneered with Plug and Play will be required to insure interoperability with each mobile platform as well insuring that your device plays well with other devices using the wireless connectivity. In essence, some things never change, scenarios we worked through in the early ’90s for Windows are with us today, just in a different packaging and now wireless. Which means right now there’s probably a Connect a thon running somewhere in the world….
Another former ‘Softie Evangelist, Alex St. John is blogging about the DirectX days. Lot’s of interesting ideas and history in his blog, but one topic caught my eye: Evangelize early. I couldn’t agree more. Alex talks about the DX team working with the game industry before anything in DX was really working, making it participatory and getting the game developers to invest long term by working along side the team on the same timeline release to release. Great tactic if you can pull it off, and was in the Microsoft Evangelism Playbook for years.
This sounds pretty early doesn’t it? Well, I’ve got an example that is even more extreme. Believe it or not, I evangelized Windows NT for Microsoft when it was just a stack of papers. I flew around the world with some of the leaders of the original Windows NT development team conducting design reviews of Windows NT *paper specs* with our key ISVs before any code was running, not even a demo. Why? Remember at the time Windows was moving from 16 bit to 32 bit, adding real multitasking and virtual memory as well as the ability to implement protected subsystems running things like POSIX compatible API shells. We were interested in whether ISVs wanted Win32 to track the semantics of Win16, or could we “do the right thing”. Pretty universally the answer was, do the right thing and don’t saddle us with a legacy design from Win16. Whew, that’s exactly what we wanted to hear.
Doing things this early is quite risky, you tip your hand to the competition. You may be in fact wasting your partners time if the product either doesn’t ship or is radically different in the end. But in this case, it was warranted and we were rewarded with both early support and an architecture and an API pattern that served the industry for 20 years.
Our BlackBerry 10 evangelism effort implemented some of these best practices. A full nine months before launch we provided more early seed units to the worldwide developer community than BlackBerry or anyone else in the mobile industry has before, to the best of my knowledge. While we didn’t review paper specs, (that would have been at least a year before I joined the company), app developers did incrementally familiarize themselves with our early builds of BlackBerry 10, provided feedback along the way and ultimately rewarded us with an industry record level of early support for a new platform at launch.
When is the right time for you to begin evangelizing your product?
It was 1989 and Microsoft was facing down a daunting three pronged product strategy: first to continue evolving DOS, second to garner support for the nascent DOS based GUI environment named “Windows” and third building an entirely new operating system with then partner IBM called “OS/2”. How can the company possibly deliver application software for all three operating systems?
Ever vigilant of competitors strategies and tactics, Microsoft noted the seeming success of Apple Computer’s “Evangelists”. A team was quickly assembled to answer this Apple threat, and in what would be become a common Microsoft tactic, made the role it’s own by tweaking the title to “Technical Evangelist”. This team was called the Microsoft Developer Relations Group and was Microsoft’s first evangelism team. I was part of this team and the lessons we learned way back then continue to be applicable today.
From the beginning Microsoft’s Technical Evangelists were very different than Apple’s team. First and foremost, we were all developers. We had coded apps for Windows, Unix, workstations, mini and mainframe computers. In contrast most of Apple’s Evangelists were MBAs and were non-technical. Secondly, our evangelists were laser focused on helping partners deliver their code, gain distribution in the channel and market their products. Apple Evangelists, in a weird bit of foreshadowing, delivered an “experience meeting” more like a big tent revival. As the other Japanese American technology evangelist in the industry at that time, I was always hearing comparisons to Apple’s Guy Kawasaki. Although he and I had the same goal, to lock up ISV platform investment, we employed very different tactics. During these early days of evangelism I heard many times that “Guy was here last week…” then “.. you guys are very different…” and most importantly that “… we’ve decided to do the Windows version of our app first”.
I’ve never forgotten this lesson. Every Evangelism, Ecosystem and even Business Development teams I’ve built are made up of articulate, driven, technical, and entrepreneurial individuals. My BlackBerry Developer Evangelism team is yet another example of hiring to this model. Many of my current team have run their own startups and are already identified as industry luminaries in their area of specialization. Ok, a few of them also have their MBAs, we try not to hold that against them.