Empowering Linux Developers for the New Wave of Innovation

snapcraft logo

New businesses with software at their core are being created every day. Developers are the lifeblood of so much of what is being built and of technological innovation, and they are ever more vital to operations across the entire business. So why wouldn’t we empower them?

Machine learning and IoT in particular offer huge opportunities for developers, especially those facing the crowded markets of other platforms, to engage with a sizeable untapped audience.

That Linux is open source makes it an amazing breeding ground for innovation. Developers aren’t constrained by closed ecosystems, meaning that Linux has long been the operating system of choice for developers. So by engaging with Linux, businesses can attract the best available developer skills. 

The Linux ecosystem has always strived for a high degree of quality. Historically it was the Linux community taking sole responsibility for packaging software, gating each application update with careful review to ensure it worked as advertised on each distribution of Linux. This proved difficult for all sides.

Broad access to the code was needed, and open-source software could be offered through the app store. User support requests and bugs were channelled through the Linux distributions, and there was such a volume of reporting, it became difficult to feed information back to the appropriate software authors.

As the number of applications and Linux distributions grew, it became increasingly clear this model would not scale much further. Software authors took matters into their own hands, often picking a single Linux distribution to support and skipping the app store entirely. Because of this, they lost app discoverability and gained the complexity of running duplicative infrastructure.

This placed increased responsibility on developers at a time when the expectations of their role was already expanding. They are no longer just makers, they now bear the risk of breaking robotic arms with their code or bringing down MRI machines with a patch.

As an industry we acknowledge this problem—you can potentially have a bad update and software isn’t an exact science—but we then ask these developers to roll the dice. Do you risk compromise or self-inflicted harm?

Meanwhile the surface area increases. The industry continues a steady march of automation, creating ever more software components to plug together and layer solutions on. Not only do developers face the update question for their own code, they also must trust all developers facing that same decision in all the code beneath their own.

Read More

Leave a Reply