이 1%라는 수치가 어디서 나온 것인지 정확히 모르겠지만, 1,400만 명의 사용자 중 1%라면 14,000명이 Discourse에서 배제되는 셈입니다. CSS와 성능 조정 몇 가지를 위해요?
"최신 소프트웨어의 이점을 누리지 못하게 막을 수 있는 사용자 수는 몇 명이어야 합니까?"라는 질문에 대해… 왜 그 수치가 1%보다 훨씬 적고, 0%에 훨씬 가까운 값이 될 수 없을까요? Discourse는 반대 접근 방식을 취해야 한다고 주장합니다. 즉, 반드시 필요한 중대한 수정 사항이나 이를 절대적으로 요구하는 주요 기능이 있으며, 동시에 이에 대한 광범위한 사용자 수요가 있는 경우를 제외하고는 불필요하게 후방 호환성을 깨는 변경 사항을 하지 말아야 한다는 것입니다.
그 질문의 역문은 "낮거나 없는 사용자 체감 영향을 가진 사소한 편의 기능을 쫓기 위해 몇 명의 사용자를 차단할 의사가 있는가"입니다. 정밀한 벤치마크를 제외하고는 거의 눈에 띄지 않을 작은 성능 향상을 위해 14,000명의 사람들을 그들의 커뮤니티에서 차단하는 것이 합리적일까요?
포럼 사용자들은 어떤 "최신 소프트웨어"를 갈망하고 있는 걸까요? … 이건 포럼입니다. 사람들은 텍스트를 읽고 텍스트 게시물에 답글을 달죠. 실제 고객들이 "왜, 이 기능들은 아무 의미도 없고 당신들은 실제 사람들을 차단하고 있다"고 말하고 있는 동안 개발자들이 계속 "우리는 앞으로 나아가야 한다"고 말하는 것이 무섭습니다.
Discourse와 같은 안정적이고 오래된 포럼 소프트웨어라면 기대할 법한 정반대의 접근 방식이라고 느낍니다. 새로운 기능을 실험하고 싶다면, 사람들이 명시적으로 선택(opt-in)해야 하는 불안정한 카나리(canary) 브랜치에서 이루어져야 하며, 메인 브랜치는 기본적으로 LTS(장기 지원)여야 합니다. 점진적 향상(progressive enhancements)을 제공하지는 못할망정, 우아한 열화(graceful degradations)도 제공하지 않고 있습니다. 이것은 소프트웨어 개발의 본질적인 부분이 아니라 선택의 문제입니다. 사용자들이 따라올 수 있는 속도보다 빠르게 움직이고 있는 것입니다.
그리고 호스팅된 커뮤니티에는 선택지 자체가 없습니다. 테크 데모나 JS 놀이터가 되기 위해, 그리고 커뮤니티를 위해 당신에게 돈을 지불하는 사람들 말이죠.
이것이 문화적 문제이지 기술적 문제가 아닌 이유입니다. 적어도 이를 소리 내어 말해 주셔서 감사합니다. 개발 시간과 예상되는 사용자 영향 사이에서 이 비용의 장단점을 저울질해 보았고, 당신의 계산에서 사용자는 기본적인 게시판을 만드는 데 드는 비용보다 가치가 낮다고 판단한 것입니다. 다르게 말할 방법이 없습니다: 당신들은 개발자의 편의를 위해 실제 사용자와 커뮤니티를 그만큼 가치 있게 여기지 않는 것입니다 
이 인용을 조금 맥락에서 벗어나서 말씀드리자면… 백분율 단위로 생각하는 것을 멈추고, 커뮤니티 내 실제 개별 개인에게 미칠 영향을 생각해 본다면, 계산 결과가 달라질 수도 있지 않을까요?
이 전체 사안은 다소 스탈린주의적입니다. 하드웨어를 업그레이드할 만큼 가난하거나, 다른 운영체제나 호환성 레이어 또는 브라우저 포크를 설치하기 위해 복잡한 과정을 거칠 의지나 능력이 없기 때문에, 수년 동안 소속되어 온 포럼에서 텍스트 메시지를 계속 게시할 수 없게 되는 것은 기본적으로 일회용 통계 수치에 불과하다고 사람들에게 말하는 것이죠.
이러한 비용-편익 분석은 완전한 재작성과 같은 주요 새 버전에서 기대할 만한 것이지, 작은 성능 이점이 있을 수 있는 사소하고 눈에 보이지 않는 개발자 지향 기능에서 기대할 만한 것이 아닙니다 =/贵公司가 이 입장을 취하고 있는 것은 정말 안타깝다고 생각합니다. 하지만 여전히… 투명성에 대해서는 진심으로 감사드립니다.
자, 어쨌든 불평은 여기까지 하겠습니다. 잠재적으로/기대적으로 더 건설적인 질문이 하나 있습니다…
기본 HTML 모드가 소수의 사용자에게 도움이 될 수 있지만, Discourse가 자체적으로 구축하는 데 자원을 투입하고 싶지 않은 것이라면… 오픈소스 커뮤니티가 이를 잠재적으로 떠맡을 수 있는 실현 가능한 일일까요? 플러그인 같은 것에는 너무 크고, 완전히 별개의 프로젝트(예: Discorkie)에는 너무 작아 보입니다.
현재 API와 함께 작동하는 대체 오픈 프론트엔드로 범위를 설정해 보는 것이 conceivable(상상할 수 있는) 일일까요? 그리고 만약 가능하다면, 그러한 것(언젠가 구축되고 테스트된다면)이 메인 소프트웨어에 “공식적으로” 수용/통합될 가능성이 있을까요? 호스팅된 Discourse 인스턴스에서도 사용할 수 있도록 (제 영향받는 커뮤니티 중 하나가 그곳에 있으니까요).
그 맥락에서, 그러한 대체 프론트엔드가 추적할 수 있는 어떤 종류의 API 버전 관리/안정성 시스템이 있습니까?
아마도 여러 이유로 여전히 다양한 "아니오"가 답일 수 있고, 그렇다면 괜찮지만, 만약 조금이라도 실현 가능하다면… 생각해 볼 가치가 있을지도 모릅니다. 대규모 타당성 조사를 요구하는 것이 아니라, 그저 직감적인 의견 정도를 듣고 싶습니다.
그런 것이 실제로 성공하거나 유지될 수 있을지 확신할 수 없습니다. HTML과 최소한의 JS를 사용하여 오래된 소프트웨어를 작업하는 것을 좋아하는 개발자는 많지 않지만 (HTMX 팀과 같은 몇몇은 여전히 있습니다). 그냥 생각난 것일 뿐입니다.