시각 장애인을 위한 키보드, TapType 개발 후 오픈소스(Open Source) 공개에 대한 고민

TapType 개발자는 시각 장애인 사용자를 위해 터치스크린 키보드(Touchscreen Keyboard)의 접근성 문제를 해결하고자 했다. 기존 키보드의 시각 의존적인 인터페이스(Interface)를 개선하여, 제스처 기반(Gesture-based)의 새로운 입력 방식을 고안했다. 특히, TalkBack과의 호환성 문제를 해결하기 위해, 접근성 서비스(Accessibility Service)를 활용하여 데이터 미저장 정책(Zero-Retention Policy)을 구현했다.

개발자는 코드 공개를 망설이는 이유로 병합 요청(Merge Request)에 대한 부담감을 언급했다. 오픈소스(Open Source) 프로젝트는 기여(Contribution)를 장려하지만, 개발자는 자신의 시간(Time)을 효율적으로 사용해야 한다. SQLite의 사례처럼, 코드 공개가 반드시 기여를 의미하지는 않으며, 개발자는 자신의 프로젝트(Project)에 대한 통제권을 유지할 수 있다.

일부 사용자는 코드 미공개를 악성코드(Malware) 의심의 근거로 삼았다. 개발자는 무허가 접근(No Permission), 데이터 미저장 정책(Zero-Retention Policy), 그리고 사용자의 피드백을 통해 의심을 불식시키려 했다. 하지만, 악성코드에 대한 우려는 코드 공개 여부와 관계없이 지속될 수 있으며, 개발자는 자신의 판단(Judgment)에 따라 결정을 내릴 수 있다.

Flexy 사례는 확장성(Scalability)과 사용자 요구(User Demand) 사이의 딜레마를 보여준다. Flexy는 시각 장애인을 위한 키보드로 시작했지만, 더 많은 사용자(More Users)를 확보하면서 원래의 목적을 잃었다. 개발자는 TapType가 Flexy와 같은 길을 걷지 않도록, 자신의 목표(Goal)를 유지하고, 핵심 사용자(Core Users)의 요구에 집중할 필요가 있다.