Stop the presses! I’ve got some news. The great team at GDGT is coming to Seattle, and they are having a bit of a party and meetup. There should be a great deal of nerdosity going on there, which is awesome in its own right. This will be further accentuated by the fact that the Windows Phone 7 team will be there to show off some devices.
Under normal circumstances, that would be pretty cool. However, we’re not in the “pretty cool” business here. I think I have made it clear, we are in the epic shit business. Apparently, the nerdosity is expected to flow especially high at this event, and the request was made for the developer platform team for Windows Phone 7 to make an appearance. Challenge thrown down. Challenge accepted. Challenge contorted into something all together different.
Since announcing the email alias to which you can send your device requests (about 2 weeks ago), we’ve been blown away by the response. We’re still making our way through those requests, getting them into a CRM system and assigning them to our field evangelists. That’s a tale of logistical complexity for another day. However, the whole point of having preview devices is to get them into the hands of developers, right? So we have two things to share.
First, if you are a developer in the area, and want to come to the event, bring your laptops with your Windows Phone 7 XAPs. We will have phones on site to which you can deploy your code. You can see it running on a real Windows Phone 7. You get to share it with the crowd. That’s not bad, but certainly not epic. No, no. Epic is in reserve for those true hackers who show up with the goods. For those who have got the best XAPs, we are bringing a couple of phones with us, and some developer agreements to sign. That’s right…the “A” gamers will be walking out with phones on which to continue their coding.
In the last couple of days since Andy’s announcement that all employees would get free Windows Phone 7s, we’ve seen a lot of buzz about the offer, including some around why we were doing it.
So why did we do it? Put simply, we did it for the employees. If you speak to any software developer or hacker, they will tell you that they love writing code. They love solving problems. They love creating things. They love sharing their work with their friends and peers. They love the satisfaction of seeing something work on a screen. Unfortunately, when you work for a company, most of them generally have pretty stringent rules about moonlighting, and the ownership of IP. For software companies, this usually includes code and side projects. Microsoft is no different.
With this new mobile app era upon us, the Windows Phone team felt it important that we enable our own employees to participate. There are so many talented, technical people at Microsoft. It’s not just professional software developers…many Microsofties love coding, and they work on projects in their spare time.
We believe most Microsofties want to write apps for Windows Phone 7. Before last week, and the changes announced in our policies, they couldn’t. They would not have been able to profit from those projects. We made these changes specifically to address the desire of our own employees to express themselves in code in the app marketplace. A funny thing happens when you remove friction and barriers among a group of creative people. I can’t wait to see what they create.
The internal response has been overwhelming. I can’t count the number of languages in which we heard “thank you” while at our global sales summit last week.
The first previews of Windows Phone 7 are starting to hit, and they all feel fair and balanced, which is always appreciated. Engadget certainly goes in depth on their preview, as does PC Mag. However, it was this unboxing video which made me smile the most, if for no other reason than it was the box I designed with the help of a fellow Liverpool Football supporter. He’s really the brains behind the operation. My contribution can be seen at around 2:30 of the video. OK, off to our global sales summit to spend some quality time with our field sales team members, and spread the word on Windows Phone 7.
There was a story which surfaced yesterday about vulnerabilities exposed in a wide swath of Android apps. SMobile Systems conducted research in the Android app space and found that some 20% of the apps allow third-party apps to gain access to sensitive or private information.
It would be easy to dismiss this article by pointing out that by simply downloading an app, a customer is making a explicit allowance to an app to access data on the phone. What I found troubling about the findings wasn’t necessarily the point about access to the data, but rather that, 5% of the apps surveyed could make calls and 2% could send premium SMS messages. Talk about a surprise cell phone bill.
The key word in the above statements, however, is “could.’” Yes, customers make the decision to download those apps, but they have no way of knowing with certainty what those apps are doing behind the scenes. UPDATE: Ben points out below that the customer us warned of all the APIs used, which is true, but they aren’t told *how* they are used.
Further, because of the multi-tasking architecture of Android, the apps have the potential to be doing a bunch of bad things in the background when the phone is not in use.
Google has been quick to point out that the architecture of Android would limit what actual damage one of these apps could do, but that’s really not the point. What is being lost in this discussion is that there is no curation of the Android marketplace. For all the grumbling and grousing about the Apple AppStore, their review process would likely catch these abuses. There is no such level of certification for the Android marketplace. Customers don’t want to think about needing anti-spyware software for their phone, as the article implies is one solution for Android.
The Windows Phone Marketplace certainly believes in the curation model, and we have placed user security as a top priority. This is one of the main reasons that we have our app certification process, and why (UDPATE: “at least in version 1”) apps are run in sandboxes, with no access to any data other than its own isolated storage, or the ability to communicate with other apps. UPDATE: The goal is to ensure that absolute best customer experience when using their phone.
UDPATE 6/25/10
I’m not one who believes in conspiracy theories or anything, but I do find the timing of this announcement from Google that they can remotely wipe apps from phones a bit curious. I have to go do some digging, but I’d be interested to know if the Android developer agreement has specificity about what would constitute grounds for a remote wipe.
Inspired by the always entertaining Mike Klucher, I snapped this pic of my own avatar on my daily use Windows Phone 7. He talks about the very way I felt when my avatar showed up on my phone this week. It made me smile. I even went into the XBox Marketplace to change around some clothing options to see how long before it appeared on my phone. I was not disappointed.
I also felt great sadness because my achievements were so dated. Not that the system wasn’t working. No,no. This was a stark reminder that I haven’t been playing nearly as much XBox as I should be!! So, off to GameStop I went and picked up my copy of Red Dead Redemption. I very much plan to use the “hey, it’s Father’s Day” excuse all weekend long.
Well, there’s an old adage that you should be careful what you ask for because you might just get it. The avalanche of emails and phone calls looking for developer devices was a welcome development. There are some out there who think that we might as well pack it in on this whole mobile thing. Developers, however, know better. New markets == new opportunities for big ideas to break through.
I personally have seen, erm, a surge in the amount of email I get on a daily basis, thanks in no small part to Long Zheng. I love that there are so many developers with so many great ideas wanting to get phones, and I particularly love all the electrons being harmed to fill my inbox. My email is the one that’s out there [brwatson (at) microsoft], but there’s a whole team of evangelists who will be getting the phones to developers. I’m just acting as a switch, and have been fortunate enough to be something of a public face. We’re still working on the specific plan details for devices going out next month, but we wanted to lay out some principles for how we are going to actually get phones in developers’ hands, as well as what we are hearing from developers.
First, we are going to prioritize for apps being built by large and small teams, which represent some pretty big ideas, specifically targeting the launch timeframe. At Mix10 we showed a pretty long list of partners, and we have continued to add to that over the last few months. Second, as some of you may have heard, we are getting phones to our existing published Windows Phone Marketplace ISVs. There’s several thousand apps and companies who are part of the 6.x marketplace, and we want to help jump start their transition to Windows Phone 7. Finally, we are prioritizing for those committed developers who are building apps for Windows Phone 7 and sharing their knowledge about Silverlight, XNA and Windows Phone 7.
It’s been an interesting handful of weeks. I’ve been spending a lot of time in the field with our country managers as we get ready for the coming launch of Windows Phone 7. That’s a post for another day.
I’m here at TechEd, and there’s a lot of talk about Windows Phone 7 devices and when they are going to be made available. One cool thing that the team is doing is handing out coupons to event attendees redeemable for general availability devices when they start shipping. We’re only handing out around 50 or so of these coupons, so it’s definitely not a broad distribution. It’s meant for people who are attending sessions or wearing Windows Phone hats around the show floor.
Developer devices are also on everyone’s lips. During the Windows Phone session yesterday, Terry Myerson (he runs engineering for Windows Phone 7) stated that we will start putting phones into select developers’ hands next month. That’s exciting stuff. Obviously we’re starting with the developers who have invested in the Silverlight and .NET platforms, registered at Windows Phone Marketplace and have begun building apps with the Windows Phones Developer Tools. Specifics of the programs are TBD, but we are going to want to get phones into large ISV hands, small team hands…you name it. We’re definitely not going to carpet bomb phones; we want to get maximum leverage for our phone distribution to developers.
Stay tuned, and go download the developer tools. If you need inspiration about what amazing apps you can build, check out this post from Anand about the Imagine Cup winners. And if you want to show some gumption and reach out to me directly, have at it.
This past week, I participated in a backstage conversation with the community interested in Windows Phone 7. It a very strange experience for me, which you will understand when you watch the video. Between lights going out, phones ringing, and talking to a screen for an hour, it was most certainly novel. I enjoyed it thoroughly and look forward to doing another. Lots of great questions from the community. Have a watch and let me know how I can help you.
Courtesy of the fine folks at Remix Atlanta, I found myself being interviewed by the very Southern-courteous Celia Dyer for TechDrawl. They’ve finally posted it. The audio was best we could manage given the space we had, and the impromptu recording. Enjoy.
One of the hardest things about shipping software is shipping software. During the final testing phases for our Windows Phone Developer Tools CTP refresh, we discovered a bug that will impact developers using some existing “transparent Silverlight” assemblies (Microsoft & 3rd party) in their Windows Phone applications. So we had a choice to make: 1) pull back the release to fix the underlying problem (which may have taken up to two weeks given where the actual problem exists and how the engineering & test work required to validate the fix didn’t cause other regressions), or 2) shipping what we had with relatively simple work around.
I like to tell everyone who will listen to me that my job is to be the number one and loudest advocate for our Windows Phone developer experience. Since so many of you have already updated to the recently released Visual Studio 2010 final release, I didn’t want our community to wait any longer for access to the updated Windows Phone tools. We feel confident that this issue impacts only a small subset of Windows Phone developers, but we want to be as transparent as possible about this issue, and get the word out about the work around as quickly as possible.
The Bug – System.IO.FileLoadException
When loading assemblies that make up an application, the Windows Phone OS checks their digital certificates. There are 3 types of assemblies:
1) Those included with the phone – these are signed with a Windows Phone cert
2) Those that are provided by other SDKs – these are transparent Silverlight assemblies, and are generally signed with some other cert
3) Those that are built as part of your app – these are your source code, and in this release they aren’t getting signed
In one of those “d’oh” moments, we found that the loader, in this iteration of the Windows Phone Developer tools, fails to load assemblies that are signed with non – Windows Phone specific certificates. So any signed SDK assembly will fail to load. This issue will surface if you are trying to use transparent assemblies from toolkits such as the Silverlight SDK (e.g. to use the RSS capabilities found in System.ServiceModel.Syndication.dll).
The problem is specific to this release of the Windows Phone Developer Tools. It will be fixed in a future update.
In one of those “d’oh” moments, we found that the loader, in this iteration of the Windows Phone Developer tools, fails to load assemblies that are signed with non – Windows Phone specific certificates. So any signed SDK assembly will fail to load. This issue will surface if you are trying to use transparent assemblies from toolkits such as the Silverlight SDK (e.g. to use the RSS capabilities found in System.ServiceModel.Syndication.dll).