Microsoft Lync 2013 Software Development Kit moving from Mainstream Support to Extended Support April 20 – my thoughts

There are some interesting support milestones this month from Microsoft Support.

On April 10th, Microsoft Lync 2013, Microsoft Lync Phone Edition, Microsoft Lync Server 2013 (all editions), and Skype for Business 2015 all transitioned from Mainstream to Extended Support.

On April 20th, the Microsoft Lync 2013 Software Development Kit will transition from Mainstream to Extended Support.

The Lync 2013 SDK is the client-side SDK and is what developers use to write applications that interact with, control and take information from the client. The 2013 version was the last version of the SDK – no new SDK was released with Skype for Business 2015 or 2016.

What does this mean for my applications written with the SDK?

It’s good to understand exactly what Extended Support is and how it’s different from Mainstream Support. It’s not the same as no support. That’s called End of Support, and in January it happened to Microsoft Office Communications Server 2007 (all editions), Microsoft Office Communications Server 2007 R2 (all editions), Microsoft Office Communicator 2007, Microsoft Office Communicator 2007 R2, and Microsoft Office Communicator 2007 R2 Phone Edition  (amongst others). This really is the casting out into the wilderness: no new security updates, non-security updates, free or paid assisted support options or online technical content updates. You’re on your own.  (and by the way, it’s happening to Lync for Mac 2011 and Lync Meeting room in October this year!)

In contrast, Extended Support lasts for a minimum of 5 years and includes security updates at no cost. However, there won’t be any non-security updates (unless you want to pay for them), and there’s no support. Additionally, Microsoft will not accept requests for design changes or new features during the Extended Support phase. If you’re using these products, you’re not at danger by continuing to use them – but you don’t get any help to keep them running, and there’s definitely not going to be any improvements.

So, as Lync SDK developers: the SDK you’ve used to build your application is not suddenly going to have unpatched security holes – but if you find any problem with it that aren’t security related, it’s unlikely they’ll be fixed. In addition, no more features or enhancements. If you’re happy with this; then you’re free to continue to use the SDK to produce applications that enhance user’s desktop experience with Lync and Skype for Business, but you might want to consider how you word your contract with users around supportability – as you might become subject to a bug that’s not of your making and that you can’t get fixed.

What about Skype for Business 2019?

We already know that Microsoft are committed to the next version of Skype for Business, called 2019. What we don’t know yet is whether or not it will ship with an updated Software Development Kit. It would be really nice to see a refreshed SDK that included some of the newer client features which aren’t currently supported. However, (and this is said without any prior knowledge) I’m fairly skeptical this will happen, as so much of the development effort at the moment is going into Teams. It’ll be interesting to see whether the Lync 2013 SDK works with 2019 clients, but even if it does, companies and ISVs will have tough choices to make about whether they want to run out-of-mainstream support code in their environments.

Looking Back

At first glance, it’s easy to be critical at the lack of change in the developer tools for Microsoft Lync and Skype for Business. Since Lync 2010 there really have been only small and incremental improvements to the developer tooling, and even those have dried up in the past few years. But that point of view doesn’t really do justice to the fact that, out of the gate, Lync shipped with such a complete array of developer tools that developers haven’t really been left wanting since that launch 8 years ago.

I’m reminded at this point of a story I was told, about Microsoft in 2001. Remember what Microsoft in 2001 was like?

I was at university. TAPI (Telephone API) and CTI (Computer Telephone Integration) had been around for a few years. And, far away in Redmond, Microsoft was thinking about how they should get into the telephony game.

There was a team at Microsoft assigned to this task. Specifically looking at how people worked with a computer and a phone. They would be working at their computer when their phone would ring. They would then swivel their chair away from the computer in order to answer the phone. Computer. Phone. Computer. Phone. Different worlds. The challenge was how to bring those two worlds together.

The team had semi-regular update meetings with Bill Gates, and he didn’t like any of the proposals Microsoft were discussing internally, which were all based on copying existing PBX solutions.

He kept asking: “What is our strategy?”

What is our strategy? Got more and more worked up.

“What is our strategy?”

“What is our strategy?”

Eventually, he answered own question:

“Our strategy is software”

That decision led to a software-first approach, built on a standard Windows OS, with software layers, including developer abstractions. The key is that, by itself, bringing VOIP to the computer is not enough. If the goal is to make real-time communication a feature that can be consumed anywhere – a rich set of developer tools are needed.

Needed, and provided. As I said earlier the developer toolkit for Lync really contained everything needed to change how the system worked, enhance the system with your own code, embed, extend and alter. Yes of course there were things which could have been better or things you couldn’t do that we wished we could – but actually, it was a pretty complete set of tools. How complete is borne out by the fact that they’re still in use today without really any significant updates since then. Newer APIs have come along to address a changing market (I’m thinking UCWA and Skype Web SDK), but the core tools – the client SDK, UCMA, MSPL remain constant.

Looking Forward

There’s one rubicon which those tools can’t cross though. The Skype for Business – Teams divide. Teams is just so different that they don’t even make sense there. Teams is a different model, online only and with a client that’s perpetually updating and powered by APIs. What hope for developers today, reading these announcements about support and not seeing any replacement tools on the horizon?

Well, we don’t know yet what Skype for Business 2019 will include so we can’t make any speculation either way on that.

But Teams comes with its own set of developer tools. There’s plenty of ways in which you can extend the Teams client – whether it’s by creating apps, adding tabs or creating extensions. The Bot Framework support in Teams is rich and includes support for Cards, meaning you can display rich-text, audio/video objects, buttons, menus etc to create a good user experience across multiple devices. In many ways the Bot Framework provides a great substitute for the lack of a back-end server API (Teams is a multi-tenant hosted service, so having a “UCMA for Teams” doesn’t really make sense) because it enables developers to write bots that let users communicate naturally with code. Applications like order lookup, support desk, information retrieval, actioning items, and all the other business process flow stuff that’s so important to working smarter are enabled with Bot Framework.

The developer tools, and the things you can do with them are different to those from the Skype for Business world. Not better, or worse. Just, different. Different surfaces, different constructs. For instance, there’s no direct equivalent to the Lync SDK that’s the subject of this post. That’s likely because of the architecture of the Teams client – it’s really just a website so it doesn’t make any sense. However, that doesn’t mean that you couldn’t, in theory, do all the things which the Lync SDK does for Skype for Business clients today. A rich API for events specific to a user on that machine would serve the same purpose. But Teams let you extend the user experience and inject your own content in a much more powerful way than Conversation Window Extensions ever did, and enables some of that UI customisation that was always really problematic with the Lync SDK.

Do I think that everything we developers need is provided in Teams today? No, I don’t. But I’m really pleased and excited that Teams launched their v1 product with developers very much in mind and with a rich set of tools available. Pleased because I think it shows that the “our strategy is software” mentality is still strong within Microsoft, that they understand and appreciate the need for developer extensibility. Excited to see what they follow up with and how they will address some of the gaps.

I’m hopeful that the developer experience in Teams will soon be at parity with the developer experience that the Lync team produced in 2010, and that developers can continue to improve business processes and enable scenarios on Teams. Whilst I’ll be sad to see the client SDK sunset into history after nearly 10 years I feel we’re just starting out with some new and exciting tools which can take us forward for the next 10 years.