Conan2 is great, but not just

Recipes changed, the command line interface changed, and the build system and project integrations changed depending on your usage of Conan 1. Everything changed.

With all those breaking changes, users face difficulties adapting existing projects to the new version. This lead to additional work, cost, and potential loss of productivity.

When a program undergoes drastic changes, users must invest time and effort in learning the new features and understanding the modified workflows. This learning curve can be frustrating for users, as it can slow down their progress and limit their efficiency in the short term.

This, again, adds cost and a potential loss of productivity.

Moving already working projects to Conan 2 is a considerable challenge. And it is not just about the work but also about the time and the risk of introducing new bugs.

Some users or projects may embrace the new version, while others prefer to stick with the older, more familiar version. This can result in fragmentation and can hinder collaboration between projects and teams.

And you might have to support both versions for quite some time. This, again, adds cost and a potential loss of productivity.

If you have implemented your Conan project in specific ways fully supported in Conan 1, you may find that Conan 2 no longer supports these ways. This may lead to a situation where you have to change your project to fit the new version.

And this might affect not just build engineers but also users confronted with different tool usage and integration. This brings you directly back to the topic above, Fragmentation and maintenance challenges.

The transition to Conan 2 necessitates a rewrite of recipes and significantly adjusting workflows for its users. This process can lead to a cost explosion, as developers must allocate considerable time, effort, and resources to adapt their projects to the new version.

In many cases, this expenditure may not be justifiable, particularly for companies and projects with limited budgets or tight schedules. This cost explosion can further exacerbate the negative impact of drastic changes, as users may be deterred from adopting the new version or even continue using Conan altogether.

Consequently, the developers of Conan should be conscious of the financial and resource implications that such a substantial shift did impose on parts of their user base and strive to minimize the associated burden.

When users grow accustomed to a program, they develop trust in its stability and reliability. Drastic changes can erode this trust, as users may feel unsure about the program’s future direction and whether it will continue to meet their needs.

The current situation raises the question, when will the next expensive breaking change happen? Shall users stick with Conan or invest the time they have to invest in a search for alternatives?

Some communities might be used to breaking changes. But this is not the case for the C++ community.

In the realm of C++ development, stability and compatibility are highly valued attributes. C++ has a long-standing reputation for performance, reliability, and portability, which are key factors in its widespread adoption across various industries, including finance, gaming, and high-performance computing. By introducing drastic changes to Conan, a crucial tool in the C++ ecosystem, the developers risk undermining these cherished qualities. Ensuring that C++ projects remain stable, interoperable, and compatible is vital to preserving the trust and confidence of the C++ community, as well as maintaining the language’s strong position in the software development landscape. Therefore, it is crucial for Conan’s developers to be mindful of the importance of stability and compatibility while advancing their package manager’s functionality.

Another concern with Conan is the server component’s limited openness. While the client-side part of Conan is open source, the server-side documentation is either inadequate or entirely absent. The lack of proper documentation restricts users from easily implementing their own server solutions, thereby diminishing the advantages of an open-source ecosystem.

As a result, most users rely on JFrog Artifactory, which offers a Conan-compatible server implementation. Although the C++ part of JFrog Artifactory can be used for free, its approach to open source has raised concerns about potential abuse of the open-source spirit. JFrog’s business model blurs the line between proprietary and open-source software, leading some users to question the transparency and long-term intentions of the company.

This situation not only undermines the trust in Conan as a whole but also raises questions about the broader implications for the C++ community. It is essential for the Conan developers to address these concerns and work toward fostering a more open and transparent server-side ecosystem, thus upholding the values and expectations of the open-source community.