The Developer Program Leaders survey is back! Time to refresh what we know about the work, challenges and priorities of developer marketing, developer relations and developer tooling professionals.
In the previous survey wave, we discovered that the
#1 challenge for Developer Relations professionals was growing their community.
Developer Program Leaders Survey wave 10
Are you working in:
Developer Marketing
Developer Relations
Developer Advocacy
Developer Tooling
With a developer program?
What is yours? What KPIs are you using to measure success?
Answering questions like these helps map the world of Developer Marketing, Relations and tooling.
At the same time, it helps the global community understand, relate and learn about the challenges these professionals face, the metrics they use, and where they spend their time and budget.
Full access to the findings both in a report that illustrates the highlights and key graphs, and in an interactive session where our research analysts and the community will come together to discuss key findings and impact on the industry.
A chance to win exclusive DevRelX swag
You participate in a community effort to understand and improve how your peers work and set their strategy
How long is the survey?
It is short. You’ll need ±8 minutes
This survey helps better understand how and what developer marketing, relations and tooling professionals work on, including how they:
Run their developer programs
Prioritise their work
Segment their audience
Measure success
Justify the value of their developer program to senior management and more!
What types of questions does this survey ask?
Which regional markets does your strategy target?
Which resources take most of your budget?
What are the main challenges for your Developer Relations efforts this year?
Do you segment your developer audience? How?
Here are some results from the previous survey wave.
It’s insights like these that you will be able to access by responding.
Do you want to help professionals elevate their DevRel game? Have your say!
In my past life, aka when I worked in the financial sector more than a decade ago, we built something similar to a recommendation system, when that was not a popular term yet, using neural networks, when that was more of a swear word rather than a cool AI thing. I was that weird geek that everyone tilted their heads at trying to understand what the heck I was talking about. But with the support of inspiring leadership, my team and I persevered and built a smart analytical CRM system, based on predicted customer lifetime values and Next Best Action recommendations per customer segment. Targeted campaigns based on this approach proved far more efficient than above-the-line marketing – in some cases 70% more efficient.
Shortly after that, when I moved to the tech sector, my colleagues continued to tilt their heads there too. The new job at hand was to support tech leaders to increase their market reach and revenue by explaining and predicting behaviours in the developer ecosystem. I was excitedly trying to explain the merits of segmentation – or ‘personas’ – and developer lifetime value estimations only to get very puzzled looks and a “huh?” as a response. That was back in 2012. Thankfully things have changed, and I am proud to have contributed to this change.
When DevRel was born
As DevRel became popular, building developer personas did too. The first segmentation report I authored back in 2013 was widely quoted and appreciated – it painted the profile of mobile developer personas, and provided actionable insights on how to reach them.
Keeping ears to the ground, it became clear to me that developer-facing teams needed help building their own personas for their total addressable market (TAM) rather than using mine. Driven not just by the business opportunity but also by a desire to contribute to the community, I suggested a methodology to segment developers into personas in ‘how-to’ reports and webinars. Market response was fabulous, leading to lots of successful projects where we supported DevRel and developer product teams build personas for their audience.
At that stage I pointed again to the benefits of estimating lifetime values for those segments. However market maturity was still building and there seemed to be no immediate customer need for that. And so I bided my time.
Finally, the time was ripe
One day DevRel team leaders came knocking, asking if we had any way of estimating the value that a developer brings when onboarded to their community. Something that would help them articulate the value of their teams and their budgets. Aha! Had the time come?
Then the economic environment tightened in the tech industry, and a bloodbath of budget cuts ensued. Developer marketing and DevRel budgets were among the first to suffer. With all spending scrutinised, being able to prove the effect of your efforts on the organisation’s bottomline was certainly crucial. Yes. The time was ripe.
Excuse me, does this make sense to you?
I had to check with DevRel and developer product leads that I was on the right track, that my idea made sense. Just in case I could avoid that tilted-head look this time.
I am very thankful to the DevRelX community members who answered our poll on the topic, and especially to those who took the time to speak with me and share their thoughts. Yes, a dollar value estimate per developer onboarded was definitely something they would use. Some of them had even attempted calculating it themselves, but failed as their transactional data could not yield a believable number. I was definitely onto something, and survey data held the answer.
The demon of indirect value
But why were folks failing to estimate developer value? After all, customer lifetime value has been around for a few decades already, and several approaches to its calculation have been suggested and tested across various business settings.
The developer ecosystem is unique in nature, with intrinsic characteristics that set it apart from the consumer and banking world. For one, technologies and therefore developer choices change rapidly. As a vendor’s clients, developers may come and go multiple times, using, abandoning and then re-adopting technologies in the context of different projects. ‘Lifetime’ is next to meaningless in this space. Solutions have been suggested to this problem of consumer behaviour, but they needed to be further engineered to deal with the high frequency with which developers change tooling, and the low observability of their behaviour across stacks of technologies.
The really scary “you-will-not-pass” demon, however, lay elsewhere. Indirect value. This demon resides in the retail world as well (word of mouth, referrals, ratings, reviews, etc.), but the developer ecosystem is ‘one level up’ in three key ways:
Developers are co-creators of the technology itself. They are partners, not just clients, contributing code or building add-ons to platforms and thus enhancing and evolving vendor technologies.
They are also skill-builders and advocates, supporting their peers to learn how to use vendor technologies through Q&A sites and communities of all shapes and sizes.
Last but not least (and one of the key reasons why DevRel boomed) developers are tooling decision makers within their organisations, from making recommendations and influencing decision makers all the way to approving the total tooling budget.
For example, what if a developer is not using a technology anymore or they only use a free tool, but they do answer questions about tools and platforms in developer forums, provide training videos, or contribute code? Don’t they add value?
Of course they do. In fact, testing my model with the SlashData survey data, we found that in most cases this kind of indirect value is far greater than the transactional direct value.
That was the gist of the problem. How do you measure all these indirect contributions when you can not directly observe them in your data? That’s where those who tried to estimate developer value got stuck. And that’s where my idea came in.
The Developer Engagement Value framework
The Developer Engagement Value (DEV) framework was born, and it identifies seven different types of value – direct plus six different kinds of indirect. These can all be captured through a purpose-built survey and they can be used to arrive at a total dollar value estimate per developer persona.
It’s not an off-the-shelf plug-and-play solution, but rather a tailored research service that fits the specific needs of a developer-facing business that wishes to estimate the value of its audience. It is a customisable framework. It is also applicable well beyond the realms of DevRel. It can be used in the context of product feature design, product marketing, cross-selling campaigns, retention efforts and pricing strategies. In thewhite paper I provided an example of a use case, based on real survey data, to demonstrate the merits of the approach. That was just one generic use case, though. There are far more – and I will discuss these in another post.
A sophisticated machine with an easy-to-use product
I gave DEV the attention a game-changing framework deserves, and – more practically – strived to ensure it captures value accurately in the complex multi-dimensional space of software development. Everyone we speak to is immediately sold to the idea, although the process of implementing the framework is perceived by some as daunting (ok, I didn’t totally avoid the tilted-head look this time either!). However, the framework’s end users don’t need to worry about complexity at all. All they get is an easy-to-use tool that allows working on different scenarios and seeing how developer value changes in each case. Based on these scenarios they can then select the right levers to pull to maximise the ROI of their developer-facing activities. We take care of the rest. You can dive into the intimate depths of the DEV framework here. If you want a friendly chat on this area or its application outside the DevRel environment please feel free to get in touch.
SlashData recently published a ground-breaking white paper addressing the Holy Grail of questions among Developer Relations, community managers, Developer Program Managers and more.
The Developer Engagement Value framework calculates the added value every onboarded developer brings in real dollars. This is the total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value).
In this blog post, we are diving deeper into the practical use of the framework by showcasing a real-data example of a cloud vendor and how we calculated the value of their developer community across all their products and services for four different segments.
We considered a – hypothetical – scenario where the cloud vendor wants to estimate the value of their developer community across all their products and services and is interested in doing so for four journey-related segments: students, junior developers, specialists / senior developers (specialists for short), and managers.
Using real data, we demonstrated how you can use the Developer Engagement Value framework to:
understand developer segment transitions,
prioritise audiences for outreach,
select the value-maximising initiatives for these segments,
and understand how to optimise your offerings.
Here are some of our key findings:
68% of student developers onboarded by the cloud vendor will be professionals with some tooling decision-making influence within their organisation within a year. This implies that any investments the cloud vendor makes in students will begin to bear (more) fruit in – up to – a year later in 68% of the cases.
Senior developers and specialists are the most valuable segment out of the four we considered (students, junior developers, specialists / senior developers, and managers), each developer in this group bringing $15, that is 2.3 times morethan the dummy ARPU we assumed. This speaks volumes as to why ARPU is not sufficient to capture the full value that a developer brings, and why you should therefore be adopting a full-view lifetime value instead.
In particular, specialists bring slightly more value than the managers, and that stems from higher Support and Skill-Builder value ($4.22 vs $3.73) and higher Developer Feedback Value ($8.53 vs $8.00).
Different DevRel activities are expected to boost value of different types for any given segment. More specifically, we found that among the cloud vendor’s junior developers, those who value training courses and hands-on labs are 17% more likely than those who don’t to bring usage-inducing value. These initiatives, however, seem to have only a small effect on the product-enhancing value of junior developers. Therefore, focusing on these will mostly have an impact on the usage-inducing value.
On the contrary, those among junior developers who consider documentation and sample code to be important bring 15% more product-enhancing value than those who don’t, whilst, the effect of good documentation on usage-inducing value is only 2% higher for those who consider it important vs those who don’t. Therefore, If the focus is to increase junior developer contribution and feedback, focusing on good documentation is a good strategy, as it will attract junior developers who are more valuable that way.
There is more to this story and you can read it all in the full white paper.
Yes. You read the title right. An answer to the worst nightmare of industry professionals in developer-facing roles. This includes people in Developer Relations, community managers, Developer Program Managers and more!
It’s not just us saying it; it’s the people in these roles who have expressed how challenging it is to prove the value an onboarded developer brings, and they have done so in podcasts, panels and 1 to 1 discussions we had.
That’s why at SlashData, we developed the framework that calculates the added value every onboarded developer brings in real dollars. In our thought leadership report, we show you how to calculate this dollar value by introducing the concept of Developer Engagement Value. The total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). It is a forward-looking metric that takes into account the variable nature of developer behaviour and introduces a framework to calculate developer value in real dollars.
Why do you need to know the value an onboarded developer brings?
Developers are more than mere product or service users. Developers are unarguably partners and co-creators who add value that extends well beyond the direct revenue stemming from technology usage.
Many Developer Relations (DevRel) and developer marketing practitioners struggle to prove just how valuable an onboarded developer is, and, consequently, to justify their budget investments in DevRel. Even if they do get their budgets approved, they are faced with the problem of how to optimally allocate this budget to the different activities.
But are DevRel budgets the only reason why you would need to estimate the value that a developer brings? How about when launching a new developer product? Won’t you need a way to predict how many developers this new product will attract and how much value these new developers will bring?
For decades, Customer Lifetime Value (CLV or LTV) has been used to predict the value a client will bring throughout their ‘lifetime’ (length of relationship) with a company. Model setup and estimation was fairly straightforward at the time when all we had to worry about was direct revenue and transactional data. But in the developer ecosystem and in the era of network effects, indirect revenue, influencers, open source, and developer communities of all shapes and sizes… how do you capture value?
Estimating the value that a developer brings is a daunting task, given the indirect value contributions and network effects intrinsic to the developer ecosystem. Challenges, however, begin a lot earlier in the problem definition process than the indirect value estimation stage.
Considering these four key questions will help us to define the boundaries of the problem better:
Whose value should you estimate? As discussed earlier, it’s not just those using your products. We posed this question also to our community of DevRel practitioners, and we got back a broad spectrum of answers. See the full report for a selected set of their responses.
Can you observe the developer journey? Time is a continuum and observing a developer’s journey uninterrupted in this continuum is one of the most challenging endeavours. Telemetry alone will not get you there.
How should you define ‘lifetime’? What is the time horizon for your predictions? How far into the future should you try to see and estimate value for?
Do you really need a dollar value estimate per onboarded developer? It depends on what your end goal is. For example, if what you’re trying to achieve is optimal prioritisation of DevRel initiatives, then a relative, rather than an absolute, value will suffice. If, however, you need a number for your ROI and budget calculations, then you do need a dollar value estimated.
The DEV framework
As we mentioned earlier, the concept of Customer Engagement Value (CEV) has been around for more than a decade. We built on the model proposed by Kumar et al. (2010), adjusting and extending it to capture all the forms of engagement that are typical to developers.
In a nutshell:
Our framework proposes a method of estimating the total value that a developer is expected to bring over a period of time, either by using your technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). We call this the Developer Engagement Value (DEV), and it is a forward-looking metric that takes into account the variable nature of developer behaviour.
To arrive at the Developer Engagement Value, SlashData identifies seven key areas from where developer value stems – seven value categories:
Developer Direct Value (DDV)
Supporter and Skill-builder Value (SSB)
Peer Influencer Value (PIV)
Decision-maker Influencer Value (DmIV)
Developer Referral Value (DRV)
Developer Feedback Value (DFV)
Developer Contributor Value (DCV)
Then, factoring in data from its global developer surveys, SlashData can map all the evolution paths that the developer segments of interest can theoretically take in the course of a selected forecasting period.
The next step is to build models to find the link between developer value and specific initiatives (DevRel, developer marketing, pricing strategy, or product feature design) and finally provide scenarios which show you how each initiative is expected to change the value of each segment. The framework is fully flexible as it can be applied to a single product, to a group of products or across your whole business. It is also sensitive enough to pick up nuances between similar initiatives and, as such, can provide you with granular insight on specific activities.
What can the Developer Engagement Value framework do for you? How are you planning to use it? Dive in the full version and here’s to a brighter future.
Sustainable software engineering (SSE) is the practice of minimising the environmental impact of software. It is an emerging discipline that integrates sustainability into software practices and architecture, hardware, and data centre design. The ultimate goal of SSE is to reduce the amount of carbon emissions that software applications are responsible for by integrating various approaches to the software development lifecycle. Commonly, SSE is implemented by utilising more efficient or ‘green’ coding practices, but there are a variety of approaches available to organisations and developers alike.
In our recent report titled “Who’s integrating sustainable software engineering principles?”, which was based on data collected from the 24th edition of our Developer Nation survey, we discovered that 76% of developers sometimes or always implement at least one SSE principle and that this rises to 82% amongst professional developers. In this blog post, we take a closer look at how developers’ roles, decision-making power and involvement in DevOps activities influence their utilisation of SSE principles.
Involvement in DevOps* is a powerful predictor of utilising SSE principles in development projects. These developers are responsible for implementing SSE principles, which takes place at an infrastructural level. This said, as we will soon see, developers higher up the chain of command report using SSE principles more often than DevOps practitioners, with decision-makers being the most likely to adopt such approaches. This demonstrates that whilst decision-makers provide the impetus for adoption, it’s those in DevOps roles who undertake the implementation.
Developers involved in DevOps are considerably more likely to utilise SSE than those not involved
Indeed, we see that developers involved in DevOps are much more likely to utilise SSE approaches in some capacity than those not involved. The changes in overall SSE utilisation amongst developers doing different DevOps activities, such as continuous integration or automated testing, are not meaningfully different. However, when taking a more granular look at precisely which SSE principles are implemented by developers involved in different DevOps sub-disciplines, we see that it’s those who programmatically provision and manage infrastructure and those who monitor performance and test for security vulnerabilities who implement the widest variety of SSE principles. Developers involved in these stages of the DevOps lifecycle appear to be particularly well-placed to have maximum impact, and vendors should ensure that any SSE tools and products integrate well with these parts of the DevOps technology stack.
*In our Developer Nation surveys, we don’t ask developers to self-identify as being involved in DevOps. Rather, we determine their involvement by asking them whether or not they undertake different DevOps-related activities, such as using CI/CD or creating automated tests.
Note: The Developer Nation survey is now live. You can respond and help us better understand developers and produce insights that help you address developers’ needs.
Our data also show that the more involved developers become in tool purchasing decisions, the more likely they are to integrate SSE principles into their development projects. The reason behind this is twofold:
SSE is a relatively new discipline, and so those who are not currently buying tools or components are less likely to have had the opportunity to integrate tools which facilitate SSE development into their projects.
More senior developers have a better understanding of the cost-savings and other benefits of adopting SSE principles, and so a larger incentive to integrate such approaches. They also have the power or influence to effect such a change.
Senior decision-makers are the most likely to integrate SSE principles into their development projects
We can see the effect of decision-making seniority reflected in the usage of SSE by developers in different roles. 91% of CIOs / CTOs / IT managers utilise SSE approaches, but 78% of developers in unspecialised programmer roles do as well. Currently, the implementation of SSE principles is of strategic concern, with a high-level implementation rather than taking place closer to the code. It may be that SSE approaches will follow secure coding practises and ‘shift-left’ as developers take more personal responsibility for the sustainability of their code in the future. DevOps practitioners and decision-makers will still need to be involved though – organisational and infrastructural implementation of SSE principles will continue to have a large impact.
For now, though, SSE practices are typically implemented in the domain of specialists such as DevOps practitioners and decision-makers, and we see that developers in these roles are often motivated by environmental concerns and believe they have a part to play in combating climate change. Vendors wishing to encourage the adoption of SSE products and principles may find traction in appealing to the consciences of decision-makers in organisations.
We also find that DevOps engineers and other specialists, as well as CEOs, are most challenged by measuring the impact of integrating SSE into their development projects. As companies cannot manage what they are unable to measure, it is clear that the lack of a metric is a key hurdle in SSE being more broadly adopted. Removing this pain point could also act as a push to drive adoption.
In our Developer Nation survey, we also asked which SSE principles developers are integrating. The list of SSE principles included activities such as creating carbon-efficient software, minimising data transmission, or optimising code. Looking more closely at which principles are being integrated by developers in different roles, we see that those in managerial positions are among the most likely to integrate every SSE principle we asked about in our latest global developer survey. However, given that few developers in leadership positions are responsible for the implementation, many developers who are closer to the code disagree. Programmers, architects, and DevOps engineers all integrate most of the SSE principles we ask about much less often than average. This suggests that there is a disconnect between the SSE principles that leadership wishes to adopt and what is actually implemented.
A closer look at DevOps practitioners reveals a further surprise – as we saw previously, these developers are some of the most likely to integrate SSE principles overall, but they are actually less likely than average to integrate many specific SSE principles. This indicates that DevOps engineers are selective about which principles to integrate.
This isn’t the whole story, though. Other specialists such as embedded developers or network, hardware and site reliability engineers integrate the widest range of SSE principles into their development projects – though the cumulative impact of the small numbers of developers in these niche roles is small, they are highly active in the SSE space and represent a cohort of early adopters with a wide range of involvement in SSE.
In this post, we’ve learnt that SSE remains in the realm of specialists and leadership, and whilst software development tool companies should cater to the needs of developers in these roles, it’s also worth considering how to drive wider adoption of SSE. Should you be interested in learning more, we take a closer look at developers’ motivations and challenges in the report.
For now, SSE sits firmly in the domain of specialist developers and leadership
Did you like this blogpost? Discover more about our research and have your say in the Developer Nation survey.
You’re familiar with at least one AI-assisted development tool; That’s right, the ChatGPT. Its popularity has skyrocketed in the last few months and with good reason.
It is designed to assist users in generating human-like text but it’s been helpful to developers too, as they can leverage ChatGPT to automate certain tasks, generate code snippets, assist in writing documentation, or even prototype conversational interfaces. While ChatGPT is primarily a language model, it can be used in the development process to aid in various aspects of software development.
In our 24th edition of State of Developer Nation, we asked developers if they use AI and how. This led to a dedicated chapter on all the new technologies that captivate developers’ imaginations. The data from our survey suggest that 63% of developers engaged in some aspect of AI-assisted development, making it evident that this technology is rapidly maturing and transforming from a mere trend to a valuable tool.
AI-Assisted Development: A Growing Trend
While overall engagement has experienced a slight decline of 4% over the past year, the nature of developer involvement has undergone a fascinating shift.
More developers are actively working on or learning about AI-assisted development, showing a 6% increase in engagement.
Simultaneously, the number of developers with latent interest has decreased by 6%.
This dynamic suggests that AI-assisted development is maturing and gaining practical applicability in the development landscape.
Generative AI: Unleashing Creative Possibilities
Alongside AI-assisted development, generative AI has emerged as a new and exciting technology.
With 57% of developers actively involved or interested in generative AI, curiosity and excitement abound. While AI-assisted development still leads in adoption at 17%, generative AI projects attract 14% of engaged developers.
The Many Uses of Generative AI
Developers use generative AI in three main ways:
as a helpful tool for their development process
by integrating it into projects through APIs
or even by creating the models themselves.
Ongoing investigations are exploring these usage patterns to uncover more insights into this groundbreaking technology.
Challenges and Opportunities
Although generative AI is gaining high engagement, there are factors that affect its adoption among developers.
Some developers may be hesitant to rely solely on generative models for critical or security-conscious tasks.
However, there is a growing adoption of generative AI for visual assets in software development, which reduces the risks of errors and security vulnerabilities.
Overcoming Challenges
Developers who work on generative AI models face the challenge of needing a large amount of training data.
However, certain tools offer the ability to fine-tune pre-trained models for specific tasks, making this challenge easier to overcome. As developers become more familiar with assistive and generative AI technologies, we can expect a surge in their adoption, leading to innovation and creativity.
Leadership’s Role
Interestingly, leaders in C-suite and other leadership positions show higher engagement rates with emerging technologies.
About 49% and 50% of those who approve tool expenses or budgets are actively involved in AI-assisted development.
This trend suggests that the revolution in AI-assisted development is driven by leaders who recognize its potential.
Looking Ahead: The Changing Landscape:
When we take a broader view, we see a cyclical pattern in the adoption and interest in emerging technologies. Developer interest has dropped by 5% overall, while adoption has increased by 4 percentage points.
This contrast indicates a dynamic shift in developer preferences, marking a change from previous trends.
In summary, AI-assisted development is rapidly evolving and attracting developers’ attention. Generative AI opens up exciting possibilities, and leadership engagement plays a crucial role in driving its growth. Cryptocurrencies continue to be intriguing, and the landscape of emerging technologies is constantly shifting.
Did you find this article interesting? Download the full free report to learn about:
The rest of the technologies that capture the developers’ imagination
Security threats in software development evolve at lightning speed in today’s digital age. With the average cost of a security breach in a hybrid cloud environment hovering at a staggering $3.6 million, it’s crucial for organisations to prioritize software security.
This is why we recently partnered with Cisco; to uncover developers’ exposure to API security exploits, their outlook on security, and how they use automation tools to detect and remediate threats. We did so by exploring the findings from two global surveys that targeted enterprise developers and created the “Developers and Shift-Left Security” public report.
How is our report unravelling?
1. Security is a key priority for enterprise developers
Security threats are on the rise, with our survey data proving it; in fact, a whopping 58% of enterprise developers have had to tackle at least one API exploit in the past year alone. And to make matters worse, nearly half of them have experienced multiple API exploits during that time.
As modern applications increasingly rely on microservices, securing the APIs that connect these services becomes even more crucial. But with developers juggling multiple APIs, it can be a challenge to stay on top of security. That’s why it’s essential to prioritise security from the very beginning of development to avoid wasting time and effort on reworking code and dealing with exploits later on.
When it comes to security breaches, it’s best to prevent them altogether. But if they do occur, organizations must be prepared to act quickly.
Shockingly, our survey found that only one-third of enterprise developers can resolve API exploits within one day of a breach occurring.
By treating security as a top priority from the start of the development lifecycle, organizations can increase preparedness and avoid costly mistakes down the road.
2. How do enterprise developers address security?
The philosophy behind shift-left security is all about putting security at the forefront right from the start. It’s like having a VIP seat reserved for security at the decision-making table!
By addressing security concerns early on in the development process, you can save a ton of money compared to dealing with security issues during deployment or after a security breach. In fact, our data shows that many organizations are already investing significant effort in identifying security vulnerabilities during the early stages of development, and as a result, have implemented additional security measures.
When do enterprise developers address security?
3. Automation makes things faster and less error-prone than manual operations.
We asked developers whether they use automated approaches to security, such as scanning tools or automated fixes.
The most likely group of developers to adopt automated security approaches are key decision-makers and team leads who influence, manage, or set the strategy for their teams’ purchase initiatives (90%).
This means that many developers still don’t use automation tools for security. However, it’s crucial for developers to use the best tools available to ensure they produce secure code.
In conclusion, APIs are crucial for modern software systems, but security exploits are a common occurrence.
A shift-left approach is vital for enhancing application security from the earliest stages of development.
While more than half of enterprise developers are already shifting left, less experienced developers are lagging behind. To support this approach, automation is essential, with two-thirds of developers using automated security tools.
However, developers motivated by gaining experience are less likely to use automation, so organizations need to balance the need for learning with the importance of using the best security tools available.
With the ongoing effects of the recent global pandemic and the European energy crisis, companies have had to adapt to changing environments both internally and externally. The ability to respond quickly to these challenges has become a defining characteristic of successful businesses.
We recently partnered with Aiven to explore how digital native companies have evolved their data management practices in response to these challenges.
We define “fast growth” as the approach of adapting quickly to change and innovating, which is crucial for companies that want to expand.
The data presented are based on a Q3 2022 survey of nearly 500 IT professionals at digital native companies worldwide.
What was happening in the past?
Firstly we’ll see which systems companies stopped using and which ones they plan to use in the future.
We found that when adopting a new data management solution, professionals must consider all options. Replacements occur when other products offer better benefits, not because the replaced system failed.
Data model fit is crucial when choosing a product, while pricing is essential when replacing one, especially for small businesses. Large enterprises prioritize technical support.
Fast-growing companies prioritize service availability and disaster recovery capabilities, with 43% prioritizing this when adopting a data management tool.
Inadequate backup/snapshot functionality is a common reason for replacing a tool, with 19% of fast-growing companies citing it. Conservative-growth companies are less likely to replace tools based on this feature.
While data model suitability is at the forefront of reasons for adopting data management tools, pricing is often the primary factor when it comes to finding alternative solutions.
What is happening now?
What our analysis shows, for now, is that fast-growing companies prefer fully-managed services, while conservative-growth companies lean towards self-managed solutions, except for search technologies.
Interesting highlights:
On average, companies with an eye for scaling up are 16% more likely to use fully-managed services and are highly focused on search technologies and event streaming/message queue systems.
Faster-growing companies tend to be more likely to adopt open-source search technologies, with OpenSearch emerging as the most popular search technology among them.
43% of those who work for companies with fast-growth business models prioritise service availability and disaster recovery capabilities when adopting data management products.
What does the future of management systems look like?
56% of respondents are looking to adopt at least one new system in the near future.
Relational databases currently have the lead in adoption (78% of respondents), but the demand for streaming data is increasing with the reliance on artificial intelligence, and event streaming and message queues are on track to become the second most popular data management system type among digital native companies.
In terms of fully-managed services, security and performance are the most likely features to grow in importance, while pricing and cost optimization are the least likely.
Fast-growing companies are more likely to adopt open-source data management products, while conservative growth counterparts are more concerned with scalability.
Sustainable practices are becoming more important when selecting a DBaaS vendor, with a higher likelihood of prioritizing reducing environmental footprint over-optimizing costs.
Adoption of data management tools?
We dedicated a special section of our report to measure adoption. We look at 9 data management tool categories and see what % of the respondents are currently using or planning to use each data management system type.
Does this align with your goals? Download the full free report to access all insights here.
A word from Aiven
Aiven’s cloud data platform helps your business reach its highest potential by making your data work for you. It provides fully managed open-source data infrastructure on all major clouds, helping developers focus on what they do best: innovate and create without worrying about the limitations of technology. We like to think that Aiven is not only a cloud data platform but also an extension of your team. We are dedicated to helping you to succeed by removing barriers and finding the right solutions – with the help of the best data technology there is.
About SlashData
SlashData has been surveying developers for more than 17 years. We talk to 30,000+ developers globally, on an annual basis. Leading tech brands rely on our insights for their developer-facing strategy. Leverage the rich data and our deep insights to segment, grow and engage your developer community by addressing their needs – directly.
Software is officially everywhere. Today, no matter what we do, we work in a tech business. We’ve been expecting this for a long time now. In fact, we bet our business on it.
Developers, developers, developers 2000
Before developers were coined the new kingmakers, before CEOs pointed out all companies are tech companies; SlashData was tracking software developers and trends. Nearly two decades ago, we believed developers were designing the world we were moving quickly to become. Since then, the world has changed more than a few times. Leading to the irony of the newest trend. Our daily feeds are flooded by 2 contradictory highlights:
Learning how ChatGPT and AI software like it makes our lives and jobs easier
Mass tech layoffs
Well, with every challenge comes opportunity, and we decided to take a step back and find our clarity, to see our vision once again. Up till now we have been proud to say SlashData helps the world understand developers and developers understand the world, but why?
What is the value we create as a result?
A value-first approach
We started asking – What is the core of our business? What is the reason for our existence in the vast universe of 0s and 1s? Understanding Developers is still our core. Quite simply, it’s what we do. We help technology companies, all companies, across industries, understand developers in order to make the right investment decisions. Know your customer, know your user and don’t forget – know your non-user. Then, data is still in our DNA – as it should be. How can you make decisions confidently otherwise? Intuition isn’t cutting it. Let’s face it, maybe we are in the position we are today, because too many people make major investment decisions based on hunches and assumptions. This is why SlashData is so critical to the way businesses should make decisions. Now more than ever, investment decisions must be supported by data. Decision making backed by data is the only way to optimise spending, create efficiencies and keep jobs. Lastly, once you get down to the core of what we do – we listen to the market. We listen to developers. Tools, products, and solutions must be reactively built. If you’re not addressing a need, you are creating a solution for no one’s problem. Listening to developers, hearing their needs, preferences and whys, and then reacting to it is how you do that.
Mission to the future
This is how we will empower developers to code the future. Our vision is to give a voice to the developers that is amplified and spread to the world’s largest companies to help them make the right decisions, spend less on mistakes, and effectively, (dare I say it?) make the world a better place. Here’s what will map our next steps
Vision – Empowering developers to code the future
Mission – Understand developers. Inspire the future of technology
SlashData’s Mission and Vision 2023-onwards
We have the data, it’s now your turn to listen to it and Inspire the future of technology as a result.
Have you tried NGINX? Have you worked with a web server or reverse proxy?
For those who have been living under a rock, NGINX is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache. It is also free and open-source software, released under the terms of the 2-clause BSD license in 2004.
Last year, we collaborated with F5 NGINX to explore their community. We designed a survey that ran between August and September 2022 with more than 2,000 respondents worldwide.
In this report we conduct an in-depth exploration of the following:
Profile of NGINX users.
We provide an overview of the survey respondents’ profiles in terms of their geographic location, role, and size of their organization, while also focusing on their use cases and the challenges they face in application (app) and API delivery projects.
What did we discover?
31% of all development roles also identify with leadership roles
44% of employees at large enterprises have nothing to do with security compared to 29% and 27% for those working at medium-sized and small businesses, respectively
The largest issue faced by the NGINX community is a lack of technical skills.
When it comes to app and API delivery use cases respondents are working on, we find that nearly 50% are currently using web servers, 36% reverse proxies, and 34% load balancer
Organisational approaches to APIs and the importance of App/API features.
We then dive deeper into apps and APIs, by examining the degree to which organizations are adopting four key API first practices:
leveraging APIs as sources of revenue,
designing the API first when building services,
aligning APIs to their overall digital strategy,
And designing APIs to be reusable.
Furthermore, we examine how these practices vary across company size.
We also explore how important security, scalability, and observability features are in app and API delivery projects.
One interesting highlight:
A higher share of those with no security responsibility recognises that user authentication and authorization are very important, compared to those who build security features into their apps.
Technology choices and development environments.
Moving forward, we look at the technology choices and development environments of NGINX community members, with a focus on their workloads, Kubernetes adoption/maturity, where their code is run, and attitudes towards open source software.
We examine how role and organization size affects each of these topics, and compare the profiles of those with low and very high workloads.
Some interesting findings in this chapter include:
77% of the respondents who use a container orchestration tool are using a Kubernetes-based one.
Scalability is the number one motivation for Kubernetes adoption
The top 3 code deployment environments are public cloud, web client/front-end, and on-premises servers.
Management, security, and monitoring/observability tool usage.
Finally, we take a look at which management/security and monitoring/observability tools the community uses, discuss cross-usage, and explore the differences between the profiles of those who use NGINX and those who don’t.
Among other things, we found that:
Those in SecOps roles strongly favour 3 tools in particular: Google (excluding Firebase), SecureAuth, and Duo.
44% of respondents are currently working on authentication or authorization use cases
Those in Leadership roles are more likely to depend solely on NGINX configuration management tool.
Make sure to download the complete report to find out more on the importance of App/API features as well as on the usage on monitoring, security and management tools
Interested in finding out more about your community? Let’s talk
