새로운 대안 구현을 개발할 때 기존 버전과 다른 아키텍처를 가지게 되면, 기존 버전에서 쉬운 것이 새 버전에서는 매우 어려울 수 있음. 예를 들어 proprietary 소프트웨어가 section 단위로 load/save하는 반면, 새 버전은 전체 문서를 메모리에 올리는 방식이라면 첨부파일 추가 기능을 지원하기 위해 새 버전의 전체 아키텍처를 수정해야 할 수 있음.
기존 구현의 대안으로 포지셔닝하는 것은 패배하는 명제임. "Python + X"라고 마케팅하는 프로젝트는 정식 버전과 경쟁하기 어려움. 그러나 MicroPython처럼 microcontroller용으로 설계되어 CPython과 경쟁하지 않고 다른 microcontroller 프로그래밍 환경과 경쟁한다면 성공할 수 있음.
호환성 주장과 달리 실제로는 오래된 언어 기능에 대해서도 호환성이 낮은 경우가 많아 대안 구현이 실패하는 이유가 됨. Ruby, Python의 경우 native C extension에 대한 지원 부족이 그 예시임.
Startup 창업 경험에 따르면, 기본적인 기능 추구 대신 아키텍처가 기업용 기능을 지원할 수 있다는 것을 보여주고, 차별화된 무언가에 집중했어야 했음.
개발자들은 JIT보다 언어 기능과 상호운용성을 더 중요하게 여김. 기존 프로젝트에 기여하기보다 자신의 병렬 프로젝트를 만드는 것이 쉽지만, 누구를 위한 것인지 자문해 봐야 함. 자아도취에 빠지지 않도록 주의해야 함.
Wrapper 코드는 표준에서 벗어나고 문서화가 부족해 고통을 야기함. 꼭 필요한 기능만 추가하고 기본값을 사용하는 것이 좋음.
MySQL 호환성으로 인해 TiDB가 겪은 문제와 유사함. 이론적으로는 개방형 프로토콜이지만 실제로는 Chrome이 주도함.
Hacker News 의견