Open source has undeniably revolutionized the world of software engineering. Instead of constantly reinventing the wheel, software teams now rely on reusable open-source components for low-level tasks. This shift allows developers to focus on programming that creates more business value, using tools like Docker, Kubernetes, Tomcat, MySQL, React, and Vue.js, which have become the backbone of modern software solutions worldwide.
At first glance, it may seem that with such robust open-source ecosystems, developers can concentrate exclusively on coding business logic. After all, business logic is what differentiates one company from another—it is specific, continuously evolving, and typically requires close collaboration between developers and business experts, who are often less inclined to contribute to open-source projects.
However, the reality is that a large portion of development time is still spent on non-business-oriented programming (such as installing components, setting up CI/CD pipelines, and developing non-business-related modules).
From my experience, several factors contribute to this situation, keeping software engineers involved in lower-level tasks:
Overwhelming Variety of Open-Source Components: The sheer number of available open-source tools can be a double-edged sword. While there are countless options for nearly every task, this abundance can make it difficult for developers to choose the right component. What’s popular today may become obsolete tomorrow, leading to constant re-evaluation and refactoring. It’s hard to settle on long-term solutions without risking disruption.
Configuration and Tuning: Open-source components, while powerful, often don’t work right out of the box. They require extensive configuration and customization to meet specific business needs. Developers spend considerable time reading documentation and fine-tuning these tools.
Limitations of Open-Source Components: Open-source tools come with inherent limitations due to assumptions made during their development. When developers encounter these limitations, they often have to create workarounds or contribute changes back to the open-source community — a process that can take months and may never be fully accepted by the broader community.
Stitching Components Together: Software solutions typically involve integrating multiple open-source components. Writing the “glue code” to ensure these components work together is often more complex than the actual business logic. Ensuring seamless functionality while meeting non-functional requirements (e.g. performance, security, scalability, observability…) is a significant challenge for engineering teams.
Footprint and Bloat: Many open-source components have a large footprint, with features that teams may never use. Adding multiple components can lead to performance bottlenecks and an unnecessarily heavy system. As a result, developers may opt to build solutions from scratch when only part of a component is needed.
The Missing Middle Layer: While low-level open-source components are abundant, there is a gap in the middle layer between these base components and the business logic. Components in this middle layer are business-agnostic but lack a universally accepted open-source standard. Consequently, engineering teams often build these components from scratch or heavily customize existing ones. If there were a stronger open-source consensus on these middle-layer components, engineers could focus more on adding unique business value.
Some examples of these frequently rewritten middle-layer components include:Notification Manager: A rule engine that determines when to trigger notifications, their content, and how they are delivered (cfr. my blog "Notification management - Don’t underestimate its importance and complexity - https://bankloch.blogspot.com/2020/03/notification-management-dont.html")
Authentication & Authorization: Despite the existence of many libraries, companies often develop their own variations of authentication and access control systems (RBAC/ABAC), as existing tools (e.g. KeyCloak, Zitadel, Apereo CAS) don’t meet all requirements or are too complex to integrate. are not meeting all requirements, are complex to integrate or are too complex.
Integration Logic: Connectors for protocols and formats like MQ, Kafka, or file-based integrations are frequently custom-built, as open-source libraries (e.g., Apache Camel, Zato, or Spring Integration) don’t always meet specific needs. Advanced integration tools exist (like IBM App Connect Enterprise, Informatica, TIBCO ESB, MuleSoft Anypoint Platform…), but are typically expensive and not open source (or their open source version is too restrictive for most companies).
Report and Document Generation: Tools to automatically generate reports or documents based on business data and templates.
Workflow Manager: Systems to model and manage business workflows with the necessary audit trails and controls.
Task Manager: Systems to manage manual tasks, including assignment and follow-up.
Rule Manager: Components that define and evaluate simple rules using a UI, configurable by business users without the need for code.
Simple CRUD Operations: Standard interfaces for creating, reading, updating, and deleting records, often with administrative panels.
Search and Filtering: Custom search screens with pagination, filtering, and export functionalities, common in business applications.
…
With the rise of AI, some of these issues could potentially be addressed. AI may help automate the creation and optimization of certain components, reducing manual configuration and integration efforts. AI-driven solutions could also offer smart orchestration between open-source components, making integration more seamless.
However, it remains to be seen if AI will deliver fully integrated solutions that meet the highest non-functional requirements.
Let’s hope that in the coming years, developers will be able to shift their focus entirely to creating value through business logic, rather than building and stitching together underlying components. The next frontier for open-source may lie in creating a consensus around higher-level components, freeing developers to concentrate on building innovative solutions that solve real-world problems.
For more insights, visit my blog at https://bankloch.blogspot.com
Comments
Post a Comment