The comparison between original and open source apps is missing a critical bit of info: some notion of feature parity. Some of the open source versions intentionally eschew some feature compatibility, but others are pale imitations that stall-out when the magnitude of the task is finally appreciated. Most tend to be in that large gulf.
One significant issue is the difficulty of doing organized testing. Any network email client faces significant interoperability challenges with anything more complex than POP3. Any IMAP4 implementation must (theoretically) test with multiple server implementations using a staggering set of test scenarios. This is further
complicated by the fact that essentially no
two IMAP4 mail servers really work the same way even if they provide all the mandatory protocol.
Further, the assumption that the email environment seen through a server-specific user-agent and an IMAP4 user-agent will be the same, or just two different IMAP4 user-agents, is frequently less true than scriptural purity can provide.
Another issue is generality of use cases. While Linus created “git” to replace his previous tool supporting the Linux kernel effort, git is not a simple replacement for revision control systems. From one point of view, git is an “anti-control” system. It allows arbitrarily many different people to simply copy an entire tree and do with it as they wish. The only coordination happens when a modified tree is (attempted to be) merged into a managed mainline. This is a real advantage in an environment where the BigBang/BigCrunch/Repeat cosmological model can be used.
Git is not adequate for an environment where entropy is automatically managed more aggressively. This distinction seems to be lost given the assertion of equivalence.
Different software systems exist because of different goals and requirements, not only because of political philosophy.
The comparison between original and open source apps is missing a critical bit of info: some notion of feature parity. Some of the open source versions intentionally eschew some feature compatibility, but others are pale imitations that stall-out when the magnitude of the task is finally appreciated. Most tend to be in that large gulf.
One significant issue is the difficulty of doing organized testing. Any network email client faces significant interoperability challenges with anything more complex than POP3. Any IMAP4 implementation must (theoretically) test with multiple server implementations using a staggering set of test scenarios. This is further
complicated by the fact that essentially no
two IMAP4 mail servers really work the same way even if they provide all the mandatory protocol.
Further, the assumption that the email environment seen through a server-specific user-agent and an IMAP4 user-agent will be the same, or just two different IMAP4 user-agents, is frequently less true than scriptural purity can provide.
Another issue is generality of use cases. While Linus created “git” to replace his previous tool supporting the Linux kernel effort, git is not a simple replacement for revision control systems. From one point of view, git is an “anti-control” system. It allows arbitrarily many different people to simply copy an entire tree and do with it as they wish. The only coordination happens when a modified tree is (attempted to be) merged into a managed mainline. This is a real advantage in an environment where the BigBang/BigCrunch/Repeat cosmological model can be used.
Git is not adequate for an environment where entropy is automatically managed more aggressively. This distinction seems to be lost given the assertion of equivalence.
Different software systems exist because of different goals and requirements, not only because of political philosophy.
Assertions of equivalence without regard
to these real differences can discredit
the cases where the advantages are real
to everyone’s ultimate disadvantage.
Complete agreement! I have some additional thoughts on that in tomorrow's podcast as well.