Developer Communities: A Perpetual Work In Progress

The growth fundamentals of a software company is very simple — it is a matter of adoption. Adoption can be looked upon in two general ways — in commercial terms like product revenue, or in terms of number of developers using the technology.

Very few companies get both right at the same time – either they focus on making a big commercial impact first, or they focus on building a vibrant developer ecosystem first.

This work is never really finished – it needs to evolve constantly, and that is where software companies don’t always succeed.

For companies that already have a presence in the market with an existing technology ( I don’t like the term legacy all that much) – their approach to developer communities are different than a company that is relatively new and has only one product. My past employer SAP and my current employer MongoDB both have a thriving developer ecosystem – but with interesting differences.

SAP has been around since 1972. I have been involved in the SAP developer ecosystem since the mid 1990s. It was only about 10 years ago or so that SAP formally created SAP Developer Network (then SDN and now SCN – C stands for communities ). And it is a splendid one. I have derived plenty of value from it personally as a developer, consultant and later as an SAP executive. SAP was already a big commercially successful company when SDN was started – and I firmly believed it has helped SAP tremendously. SDN membership was primarily constituted of ABAP developers when it started and probably a good part is now made of developers from BW/BI background.

So when SAP came out with new technologies – mobility, Hana, cloud etc., there was already a system in place for building ecosystems around them.

However – in my opinion, it only had limited success. SAP as a company had shifted massively in strategy to new technology like Hana – but the community impact has not been anywhere close to the kind enjoyed by ABAP or BW/BI. It hardly impacted SAP on commercial side – Hana became a billion dollar business and looks like it is continuing to grow. I read recently that there were 1300 startups now using Hana which is pretty impressive, and few thousand customers have paid licenses for Hana. So the fact that Hana didn’t attract millions of developers did not seem to decrease the wind in SAP’s commercial sails.

When I moved to MongoDB – it took me a little while to reconcile how developer adoption is measured there. MongoDB has 7 million downloads or so now, and about 10,000 downloads happen every day. This is a company that has been around only for a few years – yet developers love it. The founders still commit code here and if you walk into a MongoDB office – you will see more developers than others. MongoDB is not a public company – so revenue etc are not yet disclosed in public domain. But clearly it is not a company as big as SAP commercially. But it is an extremely fast growing company.

Both SAP and MongoDB are commited big time to be developer friendly in future too. They should be – continued developer enthusiasm is exactly what will keep SAP’s Hana business from trailing off and what will help MongoDB in becoming the next big technology company. But what exactly gets developers enthusiastic?

1. Ease of use

Developers need an easy way to consume technology. If you don’t make it easy for developers to download (or get an AMI or something along those lines) and get started (documentation, forums to ask questions etc)- they will go do something else. There are plenty of options today for a developer – so if you make it hard for a developer, its your loss. The good thing about developers is that most of them are curious by nature – so to get them interested to try something new is easy enough. What is difficult is getting a second chance to make a good impression. Also remember – what impresses a developer changes with time. What is cool today will most probably not be so cool in couple of years.

2. Ability to get support quickly

It takes time for software to mature. And it takes developers a lot of time to become experts on new technology. So it is vital that there is a community that supports and fosters developers continuously. As new features and functions get added – developers need to be informed. The easiest way to lose developers is by directing traditional marketing at them. Developer relationship is now a specialized job – and it is fast evolving. People who talk to developers need to have credibility with them. Also – this is a two way street. Product managers who do not take developer input risk bringing out a product no one uses.

3. Balancing between newbies and experts

This is extremely hard when it comes to a growing ecosystem. When I was a young “know it all” programmer, I used to get annoyed at people who would ask elementary questions without researching previous posts where the answers were already provided. And I am the newbie with elementary questions now when I go to stack overflow to get answers on newer technology. Community managers have the unenviable job of keeping developers of all kinds of experience interested.

4. Ability to put food on the table

This comes in a few different flavors. There are developers who build and sell apps as individuals . Some others work as independent consultants . Yet others work for customers, ISVs and System Integrators. Directly or indirectly, technology skills play a big part in their ability to make a good living. Many software companies forget this part. The most elegant technology might not get developer traction if all the messaging is about technology goodness – and avoids mentioning the commercial benefits, career progression etc.

5. Comparing and contrasting to what developers already know

Platform vendors have a habit of saying “our solution is so brand new and so great that you need to rethink everything when you use it”. The trouble is – developers usually think in relation to what they already know. In my own case – I think “this is how I would code it in C, how will I do it in the new shiny technology?”. I have left many technologies halfway because I could not find information that will convince me why I should not just continue with C/C++. When I learned to code in Hana – I constantly asked myself “this is how I did it in ABAP, how does it change in Hana”. Thankfully in MongoDB – there are already drivers for all popular languages, so I didn’t really need to learn anything brand new. I think that is one of the reasons behind the astounding developer adoption of MongoDB.

6. Ability to give back

Developers like to share and give back to community – at least most of us do. What tunes out developers is when the communication becomes one directional from the platform vendor to developer, with no way to give back. This is a critical aspect that vendors need to understand – allow developers to contribute back to the community and further the evolution of product. It is not easy – developers can be pretty brutal when they give feedback. Not everyone takes it well when their “baby” is described as ugly. I have provided and received such feedback and can say first hand that this can only help in the long term.

Keeping up with developers is a perpetual work in progress – but something no software platform provider can avoid. I can assure you that while you do need to develop a bit of a thick skin, you will have so much fun over time that you won’t mind the occasional pain.

Vijay works for MongoDB. Before that, he worked at IBM and SAP. Visit Vijay’s blog to lean more about him, his interests and takes on the technology landscape. Views expressed by Vijay are his personal opinions , and do not necessarily represent the views of his present or past employers. You can also find Vijay on Twitter @vijayasankarv.