20 Oct 2003
(updated 20 Oct 2003 at 23:13 UTC) »
Success in Open Source: Technical or Social Merits?
The open source community regards itself as a 'meritocracy', a system where status is based on merits. But what kind of merits? Technical?
Between two competing open-source projects, which one is expected to 'survive', the one with most features, or the one better designed?
PHP-Nuke's still deep roots among the user base seems to imply better architecture is not that important. Its competitors, Postnuke and Xoops, are better designed (and soon to appear Xaraya, even more imo) but still doesnt seem to have reach the number of Google indexed pages (how to compare user bases in open source software? Can we trust download statistics?).
One of the possible reasons for that could be that the user base consists mainly of non-programmers which can't evaluate the code base.
But another example seems to imply that is not the case:
Open Source Java Object/Relational Persistency Libraries: OJB vs Hibernate
In many comments (
2), the dispute is portrait as OJB being the design guided (which might make it less practical) and Hibernate the functionality driven, popular library.
One of the outstanding features of OJB is its Criteria API, it provides a clean abstraction to SQL-like queries in contrast to Hibernate SQL alike: HQL...
If developers were really interested (and informed) in the technical matter of which is the best way to abstract SQL, they would choose OJB's approach instead of Hibernate's. Still Hibernate is more popular, and recently implemented the Criteria API too.
Although i am tackling about a particular issue among the many ones for Object/Relations Persistency Libraries (the one i know most about), i believe it to be more or less how the rest works, given the very different philosophy behind the projects:
Hibernate's "What matters is delivering useful functionality in a timely manner" and OJB's dedication to design principles.
Regarding the question asked by myself, i do believe Hibernate has the better approach towards a succesful open source project (social merits)!
The problem with this approach is that usually later the addition of certain functionality gets impossible or too human resource intensive to be feasible, obligating architectural changes (*Nukes).
Once down that road, there are 2 options:
To keep adding just the functionality you are able to
or to make the architectural changes which might reduce the functionality you have until you are able old stuff comply with the new system, makes it counter-productive to add new features as these may have to be redone, steal time away from adding feature towards remaking the architecture (which might take a long time). And in case of libraries/frameworks it might alienate the user base if the supported API is going to change.
A successful project would need to deal with this phase very well once it is needed.