제 생각엔 Mailgun을 추천함으로써 그렇게 하고 있는 것 같습니다. SES는 10배나 더 저렴하기 때문에 초보자용 가이드가 있었으면 좋겠습니다.
또한 위에 있는, Meta가 Discourse에 좋은 홍보가 되지 않는다는 의견에도 동의하지 않습니다. 사람들이 가장 먼저 확인하는 것은 소프트웨어가 실제로 어떻게 작동하는지입니다.
아마도 VPS/“droplet” 요구 사항이 일부 사람들에게 진입 장벽으로 작용할 수 있습니다. 저는 관리되지 않는 VPS가 전체적으로 훨씬 더 쉽다는 것을 깨달을 때까지 10년 넘게 공유 서버를 사용해 왔습니다.
아마도 VPS/“드롭렛” 요구사항이 일부 사람들에게 진입 장벽이 될 수 있습니다. 저는 관리되지 않는 VPS가 전반적으로 훨씬 더 쉽다는 사실을 깨달을 때까지 10년 넘게 공유 서버를 사용해 왔습니다.
제가 말하려는 게 바로 이런 겁니다. 예전에는 Cpanel을 통해 discourse를 쉽게 추가할 수 있었지만, 지금은 더 번거로워졌습니다. DigitalOcean 마켓플레이스 앱으로 통합하거나类似的한 방법을 제공하면 진입 장벽을 낮추고, 공유 서버에서 몇 달러짜리로 포럼을 운영했던 (좋은) 옛날처럼 만들 수 있을 것입니다.
하지만 우리는 단일 제공업체에 묶여 있지 않기를 원합니다.
저는 Scaleway를 선호하고, 다른 사람들은 Hetzner를, 또 어떤 이들은 Linode를 선호합니다 …
이러한 수준의 단순함을 원하신다면, 사실 진정으로 원하시는 것은 호스팅 제공업체가 아닐까요?
개인적으로는 이것이 원했던 것이 아니었습니다. 처음에는 자가 호스팅을 더 쉽게 만들기 위한 제안이었거든요. 실제로 이후에 문서를 다시 확인해 보니 처음 설정했을 때보다 개선된 것 같지만, 여전히 비슷한 다른 앱들보다는 확실히 어려웠습니다. 사람들이 쉽게 시작할 수 있도록 패키징을 더 쉽게 만들면 도움이 될 것입니다.
Discourse를 특별히 사용하는 커뮤니티, 포럼 및 기업들의 디렉토리가 있는지 묻고 Meta에 문의한 사례가 여러 번 있었습니다. 그들은 주요 기업 및 커뮤니티를 소개하는 Discourse.com으로 안내되었으며, 일부 기업/커뮤니티는 "광고"되고 싶지 않다는 메모도 함께 안내되었습니다. 저는 호스팅된 비공개 포럼을 운영하고 있으며, 저 역시 해당 범주에 해당합니다. 
사람들이 디스코urs 플랫폼만이라면 고양이, 정치, 개, 베이커리, 복싱, 그리고 또 베이커리에 대해 이야기할 준비가 되어 있다는 건가요? 그건 솔직히 잘 믿기지가 않네요.
하지만 저는 VPS를 돌리기 전에 디스코urs 포럼이 어떤 건지 먼저 살펴보고 싶었기 때문에 디스코urs 포럼을 찾아보고 있었습니다.
설치/설정 과정이나 UI가 복잡하지 않다고 반복적으로 주장하거나, 사용자의 경험에 대해 논쟁을 벌이거나, 혹은 사용자가 자신의 경험과 의견을 정당화하라고 요구하는 것은 이전에 제가 여기서 언급하려 했던 문제들의 전형적인 증상입니다. 이것이 제가 이 커뮤니티에서 때때로 멀어지게 된 이유 중 하나이며, 매우 유감스러운 일입니다.
*디스코urs 관리자(또는 사용자)*가 시간을 내어 여기에 와서 커뮤니티에 “디스코urs 설정이 제가 생각한 것보다 더 어려웠다”고 말한다면, 그 말을 들어야 합니다. 무엇보다 먼저 그 경험의 타당성을 인정해야 합니다. 물론 그것은 개인의 의견이며, 정확히 어떤 부분이 어려웠는지에 대한 구체적 사항을 알고 싶을 수도 있습니다. 하지만 그것을 마치 그 사람이 자신의 의견과 경험을 다른 사람들과 비교하여 정당화해야 하는 요구로 제시해서는 안 됩니다. 구체적 사항이 제공되지 않거나 제공할 수 없는 경우에도, 보고 자체, 즉 사용자의 주관적 경험은 중요합니다.
소프트웨어 개발자의 일은 사용자의 고통 포인트(pain points)를 이해하려는 것입니다. 사용자가 왜 그렇게 느끼는지에 대해 정확히 알고 개발자에게 전달하는 것은 사용자의 일이 아닙니다. 이것은 소프트웨어 개발의 근본적인 도전 중 하나이며, 그 어려움에 관한 수많은 기사와 일화가 있습니다. 많은 존경받는 기술 업계 인사들(예: 스티브 잡스)조차 사용자가 자신이 무엇을 원하는지조차 모른다고 믿기 때문에, 사용자에게 직접 묻는 것이 반드시 좋은 접근법은 아니라고 생각합니다. 하지만 설령 그렇다 해도, 대부분의 사용자(관리자 포함)는 UI/UX 전문가가 아니므로, 그들이 겪는 문제를 구체적으로 식별하고 설명하는 능력에는 한계가 있을 수 있습니다.
사용자가 더 효과적인 문제 보고를 할 수 있도록 돕는 전문 지식을 가지고 있더라도, 그들이 겪은 문제를 자세히 설명하는 것은 시간과 에너지 면에서 상당한 부담이 됩니다. 이것이 사용자 연구가 수행되고, 유용하며, 또한 특정 문제를 시연하게 하거나, 하물며 설명하게 하는 것보다는 단순히 사람이 작업을 수행하는 것을 관찰하는 것이 방법인 이유입니다.
사용자(또는 관리자, 비코더)의 관점에서 유사해 보이는 다른 도구에 대한 이전 경험도 관련이 있다는 점을 인식하는 것도 중요하다고 생각합니다. 현재 커뮤니티를 구축하는 많은 사람들은 PHP 애플리케이션을 구동해 본 경험이 있을 수 있으며, 어쩌면 PHPBB와 같은 다른 포럼을 사용해 본 경험도 있을 것입니다. 그와 비교하면 디스코urs 설정은 상대적으로 복잡합니다. 물론 PHP와 PHPBB 설정 자체에는 최적화되지 않은 측면이 있고, 예를 들어 디스코urs, Rails 등에 선호되지 않는 이메일 설정을 사용하는 이유도 있습니다. 하지만 이것이 어디에도 잘 설명되어 있지 않다는 사실(단순히 디스코urs를 어떻게 설정하는가만이 아니라 왜 다른 시스템보다 어려운가 그리고 그 트레이드오프가 무엇인가에 대해) 역시 잠재적 사용자를 위축시키는 부분입니다.
마지막으로, 설치 용이성, 문서화, 그리고 셀프 호스팅이 “축복받은 경로(blessed path)”가 아닌지에 관해서는, 지난 몇 년간 Discourse.org 홈페이지의 변화를 살펴볼 가치가 있습니다. 2021년 당시의 모습은 다음과 같습니다: Discourse.org on web.archive.org from 2021
GitHub를 통한 셀프 설치에 대한 언급이 페이지에서 훨씬 위에 위치할 뿐만 아니라 직접 링크를 포함하고 있다는 점에 주목하세요. 반면 현재 사이트에서는 오픈 소스를 처음 언급하는 부분에 링크가 없고, “install(설치)”이라는 단어는 전혀 사용되지 않습니다. 따라서 GitHub 링크가 설치 링크임을(그리고 설치를 안내하는 문서가 그곳에 있다는 점을, 이는 디스코urs 웹사이트 어디에도 언급되지 않습니다) 이미 알고 있지 않은 사람에게는, 셀프 호스팅을 조사하는 것을 주저하게 만드는 미묘하지만 주목할 만한 변화입니다.
무료 오픈 소스와 특정 OS 프로젝트를 개발하는 주체의 수익 사이의 긴장 관계는 근본적인 것이므로, 이러한 변화를 이해합니다. 하지만 제게는 OS/무료/셀프 호스팅이 축소되고 있는 것이 비교적 명확하며, 이는 제 의견으로는 그것이 덜 “축복받은 경로”임을 시사하는 것입니다.
공감합니다. 아주 좋은 조언인 것 같아요.
그러니 망설이지 말고 말씀해 주세요!
설치 과정에서 어떤 부분이 어려운지, 그리고 해당 설명서를 개선하거나 새 인스턴스를 구축하는 워크플로우를 어떻게 개선할 수 있는지 구체적으로 논의해 보겠습니다.
(이 부분은 #installation 채널에서 별도의 주제로 다루는 것이 더 적절하지 않을까 싶네요.)
다만, 2017년에 제 첫 디스코urs 포럼을 인수했을 때를 떠올리면 부끄럽지만 
당시 저는 리눅스 서버에 대한 경험이 전무했습니다(과거에 유닉스 관련 교육과 업무 경험을 조금은 했기에 명령어들이 완전히 낯설지는 않았지만요).
그럼에도 불구하고 전반적으로 저에게는 상당한 학습의 여정이었지만, 그 과정을 즐겼습니다. 제 지식의 공백을 메우는 것은 제 책임이라고 생각했고, 물론 이 사이트의 커뮤니티가 큰 도움이 되었습니다.
제 생각에는 너무 “쉽게” 만들어 두면 나중에 문제가 발생했을 때 쉽게 무너질 수 있습니다. 소프트웨어와 서버는 일반적으로 매우 견고하지만, 잘못된 선택으로 인해 스스로 문제를 만들어내는 경우가 많기 때문입니다. 이는 ‘왜’ 그리고 ‘어떻게’ 작동하는지에 대해 충분히 배우지 않았기 때문일 수 있습니다(다만, 문제들은 배울 수 있는 기회이므로 대부분 즐기고 넘어가는 것이 좋습니다!).
어떤 비즈니스적 목적으로 이를 의도적으로 덜 강조하기로 한 결정은 아닙니다. 우리가 직접 돈을 받는 경우든 아니든, 어떤 Discourse 설치 환경이든 좋은 일이라고 여전히 생각합니다. 이러한 피드백에 따라 해당 링크를 다시 추가할 가능성이 충분히 있습니다.
그럴 수도 있지만, 제게 이것은 (의도치 않았을지라도) 일종의 엘리트주의를 연상시킵니다. 즉, “나는 더 어렵게 해보았고 그것이 나에게 도움이 되었다고 생각하므로, 다른 모든 사람에게도 도움이 될 것이므로 그렇게 해야 한다”는 것입니다. PHP 셀프호스팅 분야에서 수십 년을 보내고 마침내 Discourse 셀프호스팅에 도전하기 전까지 저는 PHP 도구 대부분에 대한 셀프호스팅 설치 및 유지보수가 더 쉽지만, 때로는 트러블슈팅이나 설정, 심지어 코드 깊숙한 곳까지 파고들어야 하는 유용한 학습의 순간이 동시에 존재한다는 것을 말씀드릴 수 있습니다(Discourse도 때로는 마찬가지입니다).
사실 제가 SMF, Wordpress 및 기타 많은 PHP 도구를 사용하면서 배운 모든 것은 Discourse Docker 설치를 헤매면서도 자신 있고 지식을 갖춘 상태로 진행할 수 있도록 완전히 준비시켜 주었습니다. 그럼에도 불구하고 저는 여전히 콘솔의 난해한 오류 메시지를 보고 1시간 정도 머리를 쥐어뜯다가 결국 인스턴스를 다시 구동하는 경우가 있습니다. 하지만 핵심은, PHP 셀프호스팅에서 배운 것들이 Discourse 셀프호스팅으로의 진입을 부드럽게 만들어 주었고, 그 학습 곡선은 분명히 Discourse의 것보다 완만하다는 점입니다. CDCK과 커뮤니티 전체가 Discourse를 플랫폼으로서 대중화하고 성장시키려는 시도를 할 때 이를 명심할 가치가 있습니다. 요컨대: Discourse를 설정하는 과정이 다른 곳에서 유용하고 적용 가능한 기술을 배우는 데 도움이 되어 기쁘지만, 제 생각에는 (합리적인 범위 내에서) 그 과정을 사람들에게 점점 더 쉽게 만들어 주는 것이 여전히 가치 있다고 생각합니다.
그렇게 들으면 기쁘고 실제로 그렇게 해주셨으면 합니다. 저는 미묘한 조정을 통해 문자 그대로 턴키(turnkey) 호스팅 옵션을 개요하는 것과 동시에 Discourse가 무료이며 (상당히) 쉽게 셀프호스팅할 수 있다는 점을 명확히 하고, 설치 파일과 설명서를 Github에서 찾을 수 있음을 알리는 것이 더 나은 균형을 맞출 수 있다고 생각합니다. 또 다른 예로, 많은 다른 OS 프로젝트들은 메인 내비게이션 메뉴에 문서로 직접 연결하는 링크를 가지고 있으며, 이는 일반적으로 문서의 일부로 설치 섹션을 포함합니다. Discourse.org에 이것이 없는 점(그리고 제가 본 바로 “시작하기” 링크는 셀프호스팅에 대해 전혀 언급하지 않고 이미 Discourse 인스턴스가 있다고 가정합니다)은 원할 경우 어떻게 셀프호스팅하는지에 대해 더 명확히 하는 것이 더욱 중요하게 만듭니다.
음 … 전혀 그렇지 않습니다. 오히려 제 무지를 인정하고 그것을 개선하려는 의지, 그리고 다른 사람들의 노고를 무료로 누리고 있다는 점을 겸손하게 인식하는 태도에 가깝습니다.
Discourse 설치의 난이도나 그 부재가 이 주제에 대해선 좀처럼 핵심이 아닌 것 같습니다. 현실적으로는 Discourse 사용자 중 1,000명 또는 10,000명 중 1명 정도만이 설치를 배워야 합니다. 게다가 유료 옵션도 있으니, 가격이 맞다면 포럼 설치를 위해 무언가를 배울 의무는 전혀 없습니다.
누군가 커뮤니티를 찾거나 구축하려 할 때, 일반 사용자는 "내 관심 커뮤니티와 소통하기에 이상적인 플랫폼은 어디인가?"라고 생각하지 않습니다. 그들은 그저 자신이 아는 것을 사용합니다. 그래서 제 취미 분야에서는 토론과 상호작용의 99% 이상이 Facebook/Instagram/Reddit/Discord의 조합에서 일어납니다. 제 Discourse 포럼에서 얻는 활동량과 비교하면 이 사이트들의 상호작용 품질이 너무 낮아 제게도 다소 안타까운 부분입니다(편향된 시각일 수 있지만 
정말로 이렇게 생각합니다).
이것은 인터넷의 모든 활동이 소수의 극도로 큰 플랫폼으로 집중되는 더 크고(논쟁의 여지가 있는) 문제적인 추세입니다. 상대방이 훨씬 더 많은 자원과 엔지니어를 갖추고 있는 경쟁에서 Discourse가 이 싸움에서 지는 것을 탓할 수는 없습니다. 그렇다고 해서 Discourse가 더 잘할 수 없다는 뜻은 아닙니다.
사람들은 이미 아는 것을 기본으로 사용하며, 사람들은 Discourse를 알지 못합니다. 이는 그들이 Discourse를 사용해 본 적이 없거나, 사용하고 있다는 사실을 모른 채 사용했기 때문입니다. 제 생각에 이 문제를 해결하기 위해 최적화해야 할 1순위 지표는 방문자를 사용자로 전환하는 것입니다. Discourse 포럼이 다른 많은 플랫폼보다 가진 이점은 자연스러운 검색 엔진 노출성입니다. 예를 들어, 제 포럼을 세팅하기 전까지 저는 구글 검색을 통해 얼마나 많은 Discourse 사이트를 방문했는지 깨닫지 못했습니다. 이제 저는 그걸 항상 알아차립니다. 솔직히 말해, 구글 검색을 통해 발견한 포럼에 가입해 본 적은 한 번도 없습니다(이 메타 포럼을 제외하고는요). 여기서 제가 하려는 말은, 사용자가 의식적으로 플랫폼을 실제로 사용하도록 해야 한다는 것입니다. 플랫폼을 사용하고 좋아하는 사용자들이 결국 그것을 추천하는 사람들이 될 것입니다.
Discourse가 이 잠재력을 발휘하는 것을 막고 있는 구체적인 이유는 무엇일까요? 이는 어려운 질문입니다. 이 스레드를 올린 게시글에 동의하듯, UI가 큰 요인이라고 생각합니다. 소프트웨어가 매우 유연하고 성숙하기 때문에 UI가 복잡합니다. 이는 좋은 점입니다. 하지만 그 유연성은 위에서 언급했듯이, 사용자의 경험 수준에 맞게 UX를 조정하는 데 더 잘 활용할 수 있습니다. 또는 사이트 방문자가 상호작용하고 가입하도록 장려하기 위한 다른 온보딩 도구나 인센티브 시스템을 개발할 수도 있습니다. 또한 포럼이 구식 플랫폼이며 보omer 세대들을 위한 것이라는 인식(자주 듣습니다)도 있습니다. 이는 현실보다는 인식에 가깝지만, 이를 극복하기는 어렵습니다.
이것이 언급되었으므로 부연 설명을 하고 싶었습니다. 이는 전적으로 제 개인적인 의견이지만, 저는 채팅 시스템을 전체적으로 불필요한 기능(bloatware)으로 봅니다. 다이렉트 메시지 시스템과 혼란스럽게 중복되며, 누군가에게 직접 메시지를 보내는 "또 다른 방법"은 누구도 필요로 하지 않았습니다. 이는 열등한 Slack과 Discord 클라이언트입니다. 채팅과 포럼이 상호 보완적이라는 아이디어에는 동의하지만, 이는 안타까운 일입니다. 아무도 채팅을 위해 Discord를 떠나 Discourse로 오지 않을 것입니다. 이는 놓친 기회입니다. Discord 대체가 아니라 통합이 우선순위였다면, Discord에 익숙한 사람들(매우 많은 사람들)이 Discourse에 노출될 수 있는 쉬운 진입점을 만들 수 있었을 테니까요. 아주 부수적인 이야기이지만, 이 모든 것을 작성하면서 떠오른 생각입니다.
음, 이 주제를 처음 시작한 사람으로서 적어도 제 입장에서는 이것이 정확하지 않다고 말할 수 있습니다. 사실 제 원래 의도와는 거의 정반대입니다. 제가 언급한 첫 번째 게시물과 트위터 토론은 새로운 커뮤니티를 구축하려는(즉, 커뮤니티 플랫폼을 찾는) 사람들이 Discourse의 기능과 이점을 고려할 때, 제가 생각하는 것만큼 Discourse를 자주 또는 진지하게 고려하지 않는다는 것이었습니다. 이후 사용자 경험 등에 대한 논의는 관리자가 왜 새로운 커뮤니티에 Discourse를 사용하지 않기로 결정할 수 있는지에 관련이 있습니다(예: “충분히 모던해 보이지 않는다” 또는 “너무 복잡하다고 생각한다”), 하지만 설치/설정/관리 경험에 대한 고려도 마찬가지입니다. 몇몇 커뮤니티의 현직 관리자이자 더 많은 커뮤니티의 전직 관리자로서, 제가 구축에 관여했던 모든 커뮤니티에서 이것이 분명히 주요 고려 사항이었습니다.
그렇지는 않을지 모르지만, 그 정반대(사람들이 Discourse를 떠나 Discord로 가는 것)는 분명히 일어나고 있으며, 이것 또한 Discourse에게 잠재적인 문제입니다. 저는 통합 채팅 기능 개발이 플랫폼의 최선의 이익이었다고 확실히 생각합니다. 채팅은 오늘날 주요 커뮤니케이션 매체이며, Discourse의 핵심 상호작용 방식과 경쟁하는 것이기 때문입니다. 채팅을 중시하는 그리고 Discourse가 가진 다른 몇 가지 장점(특히 오픈소스와 데이터 소유권)을 중시하는 사람은 Discord 연동(오픈소스가 아니며, 셀프 호스팅 불가, 데이터 소유권 없음)에서 이점을 얻지 못했을 것입니다. 따라서 Discourse의 모델과 정신에 부합하는 채팅 기능이 다시 한번 합리적이었다고 생각합니다(IMHO).
정말 멋진 토론입니다. 사용자 경험의 복잡성(사이트 관리자뿐 아니라 커뮤니티 구성원 모두에게)이 우리가 직면한 과제(그리고 이미 상당 시간 동안 그래 온)라는 점을 우리는 충분히 잘 알고 있습니다.
언급했듯이, 때로는 서로 충돌하는 몇 가지 목표를 가지고 있습니다. 우리는 Discourse가 altamente 구성 가능하고 커스터마이징할 수 있기를 원하며, 이를 통해 각 커뮤니티의 관리자에게 멤버들을 위한 사용자 경험의 상당 부분을 정의하는 데 상당한 권한을 위임합니다. 동시에, 초보자가 이해하기 쉽게 만들고자 하지만, 숙련된 사용자는 자신의 경험을 개인화하는 데 상당한 제어를 원한다는 것도 발견했습니다.
우리는 할 일이 많지만, 이러한 문제에 상당한 집중을 하고 있습니다. 지난 릴리스에서는 특히 사이트 설정 경험에 노력을 기울였습니다. 이번 릴리스에서는 일반적으로 관리자 경험 개선과 플랫폼의 확장성 향상에 초점을 맞추고 있습니다.
후자의 노력이 이 대화와 관련하여 흥미로운 부분입니다. 한쪽으로는 더 많은 커스터마이징을 가능하게 하여 복잡성을 더욱 증가시킬 수 있다고 볼 수 있습니다. 하지만 동시에, 특정 사용 사례에 더 잘 맞는 테마를 정의하거나, 기존 사이트의 하위 호환성을 유지하면서 더 단순한 기본 경험을 제공하는 것이 목표이기도 합니다. 예를 들어, 이 아이디어를 더 진지하게 고려하는 문을 열 수 있습니다: CDCK should develop new default Discourse themes on a regular basis to keep it looking current
이 주제에서 개발 과정에 대해 너무 깊이 들어가고 싶지는 않지만, 언급되었으므로 지난 몇 년간의 성장으로 인해 Discourse가 이제 이러한 모든 노력에서 개발자와 함께 일하는 제품 매니저와 디자이너를 포함하고 있다는 점도 언급할 가치가 있다고 생각합니다.
웹사이트에서 오픈소스를 어떻게 포지셔닝하는지에 대해서는, 우리가 논의해 온 주제입니다. 기본 플랜을 도입하고 엔터프라이즈 플랜에서 제공하는 것에 대해 더 투명하게 알려주려는 시도를 하면서 사이트가 다소 혼란스러운 상태였습니다. 여기에는 여러 옵션이 있으며, 우리는 사람들에게 자신에게 가장 적합한 것으로 보이는 옵션으로 유도하려고 노력하고 있습니다. 혼란 속에서 다소 소홀해졌고 더 쉽게 발견될 수 있어야 한다고 동의합니다. 현재는 가격 페이지의 FAQ 중 하나 아래에 있지만, 셀프 호스팅을 선택하는 주요 이유가 가격만이 아닐 가능성이 높기 때문에 그것 자체가 변할 수도 있습니다.
할 일이 정말 많습니다!
다시 한번, 여기의 토론을 정말 즐겼으며, 1년 이상 전에 시작된 토론에 새로운 생기가 불어넣어지는 모습을 보는 것이 기쁩니다. 이것이 이 플랫폼에 대해 제가 개인적으로 가장 좋아하는 것 중 하나입니다.
이것이 많은 크리에이터들이 페이스북, 페이턴트(Patreon), 서브스택(Substack)을 사용하는 이유입니다. 시작하기까지 클릭 몇 번이면 되거든요. 그리고 이 플랫폼들을 사용하는 사람이 매우 많기 때문에, 신규 사용자들이 시작하기가 쉽습니다.
디스코러스가 크리에이터들이 커뮤니티 구축을 위해 이 플랫폼을 사용하길 원한다면, 저는 그중 1% 미만만이 코딩을 배우고 싶어 한다고 생각합니다. 그들은 그저 시스템이 잘 작동하고, 자신의 사용자들이 그것을 좋아하며, 자신의 성장이 가속화되기를 바랄 뿐입니다.
제가 말하고자 하는 것은 물론 설치 장벽을 최대한 낮추는 것이 항상 더 낫다는 것입니다. 하지만 이것이 지금 논의 중인 핵심 문제는 아니라고 생각합니다. 저는 어떤 사람이 플랫폼을 추천할 때, 그 플랫폼을 사용자로서 경험한 점이 다른 어떤 것보다 더 큰 영향을 미칠 것이라고 주장합니다. 아니면 적어도 Discourse를 일반 사용자로 경험하는 사람이 Discourse를 운영하는 사람보다 수천 배는 더 많을 것입니다.
결국 저는 하향식(bottom-up) 접근법을 옹호합니다. 소수의 의사결정자들이 한 번도 들어본 적 없고 사용자들도 익숙하지 않은 이 플랫폼이 그들의 커뮤니티에 적합하다고 설득하는 것보다, 일반 사용자들이 Discourse에 매료되어 그들이 플랫폼을 위해 목소리를 내도록 만드는 것이 더 나은 목표입니다. 커뮤니티로부터 충분한 동기가 부여된다면, Discourse 기반 커뮤니티를 구축하는 데 시간과 노력을 기울이려는 사람이 많을 것입니다.
또한 채팅 기능을 너무 폄하하려는 의도는 아닙니다. 저에게 모든 것이 무료이며, 이 기능에 많은 노력과 시간이 투입되었음을 잘 알고 있습니다. 다만 제가 Discord로 쉽고 [더 효과적으로] 해결할 수 있는 문제를 채팅 기능이 어떻게 해결하는지 잘 모르겠습니다. 데이터 소유권이 누군가에게 우선순위라면 해당 논리를 존중할 수 있습니다. 하지만 같은 논리로 Discourse로 모든 소프트웨어를 클론하는 것을 정당화할 수도 있습니다.
이는 사람들이 Discord로 이주하는 것을 막지 못할 것입니다. 단순히 열등한 제품이기 때문입니다. 실제로 제 사이트에서는 공개 채팅을 꺼두어 두었습니다. 우리의 Discord와 중복되므로 그렇습니다. 우리 관리자 팀은 포럼에 직원 채널이 있음에도 불구하고 포럼의 관리자 문제를 논의할 때 전적으로 Discord를 사용합니다. 이것은 제 경험에 불과하며 전부 제 개인적인 의견이므로 제 경험에 대해서만 이야기할 수 있을 뿐입니다. 저는 에너지를 이미 많은 회사가 성공적으로 하고 있지만 그것보다 더 잘 하려고 하는 것보다, 포럼 경험을 더 좋게 만드는 흥미로운 기능을 구축하는 데 투입하는 것을 훨씬 더 선호합니다.
이번 토론에는 많은 훌륭한 지적이 담겨 있으며, 그중 상당수가 사라질까 우려됩니다. 현재 여기에는 여러 가지 다른 주제들이 얽혀 있다고 생각합니다. 명확한 초점을 두고 새로운 스레드를 몇 개 개설하면 유용하지 않을까요?
언급했듯이, 디스코urs를 거부하고 다른 플랫폼을 선택한 사람들, 디스코urs와 잘 맞지 않아 커뮤니티를 떠난 사용자들, 그리고 커뮤니티에 디스코urs를 도입했다가 후회한 사람들의 목소리를 듣고 싶습니다.
제품 관리자(PM)와 기능 과잉, 그리고 컨웨이 법칙에 관해서는 제 생각에 배울 점이 있습니다. PM에게 기능 출시를 성과로 평가하거나, 소수의 집단이 원한다고 해서 기능을 추가하면 복잡성과 이해하기 어려운 옵션의 홍수만 초래됩니다. 반면 빌드 시간, 설치 시간, 최소 사양 서버에서의 성능 등을 측정한다면 이러한 문제들을 억제할 수 있을 것입니다. 따라서 무엇을 측정하고 어떤 인센티브를 제공하는지 잘 살펴보세요.
다양한 용도로 디스코urs를 설치한 사례를 보여주는 쇼케이스를 마련하는 것은 훌륭한 아이디어라고 생각합니다. 메타(Meta) 포럼은 쇼케이스가 될 수 없으며, 단일 인스턴스만으로는 쇼케이스가 될 수 없습니다.
메타 포럼에서 창업자나 시니어 개발자가 거칠거나 무시하는 듯한 댓글을 남기는 문제는 이제 다소 개선되었을 것입니다.hopefully 교훈을 얻었을 것입니다. 하지만 저에게는 부정적인 경험이었습니다.
케이스 스터디로, 빈티지 컴퓨터 연맹(Vintage Computer Federation)은 이전에 vBulletin 사이트를 사용하다가, XenForo와 디스코urs 중 하나를 선택하는 다소 공개적인 과정을 거쳤습니다. 이 과정에는 회원 투표와 피드백이 포함되었는데, 결국 XenForo를 선택했습니다. 여기는 실패한 실험의 흔적입니다. (저는 이 일이 일어났을 때 그곳에 없었으며, 당시의 토론을 찾아보지도 않았습니다. 하지만 "discourse"를 검색하다가 우연히 이 죽은 실험을 발견했습니다. "forum"을 검색하면 성공한 후속 사이트를 볼 수 있습니다.)
저는 코딩 호러(Coding Horror)의 접근 방식을 좋아했습니다. 그의 의견에 동의하지 않을 때도 말이죠. 실제로는 여기서 불평되고 있는 기능 팽창(feature creep)을 피하기 위한 것이었습니다.
XenForo가 제 폰에서 Discourse가 A2HS 앱에서 겪는 것과 동일한 헤더 플리커(header flicker) 문제를 겪고 있다는 점이 흥미롭습니다. (Hub 앱에서는 해당 문제가 없었습니다.)
이 문제를 적극적으로 검토하고 있다는 소식을 듣게 되어 기쁩니다. 윈도우 컴퓨터를 종료하는 방법에는 매우 많은 방식이 있다는 블로그 글이 떠올랐습니다. 아마 이 글일 것입니다. 다음 글에서는 가능한 (조직적인) 이유를 제시합니다.
고찰되고 통찰력 있는 의견에 감사드립니다. 전반적으로 여기에서 재점화된 활동과 CDCK 팀의 반응은 고무적이었습니다. 이러한 종류의 문제를 모두 해결하는 것이 얼마나 어려운지 잘 알고 있지만, 문제들을 매우 잘 인지하고 있고 최선을 다해 해결하려는 노력을 기울이고 있다는 점은 큰 감사의 대상입니다.
또한 이 스레드에 최근 기여하신 모든 분들께도 감사드립니다. 흥미로운 토론과 관점들이 많았습니다. 결국, 제가 생각하는 가장 어려운 과제 중 하나는 Discourse를 인지하고 있었음에도 선택하지 않은 사용자들, 혹은 아예 인지조차 하지 못하는 사용자들과의 연결이라고 생각합니다. 이러한 ‘잃어버린 판매’ (일부는 자체 호스팅일 수 있으므로 일종의 비유입니다)에 대한 통찰은 어떤 비즈니스에게든 가장 중요한 요소 중 하나이지만, 실제로 얻기 어렵습니다. 여기에서 잠재적으로 흥미로운 아이디어를 많이 표현했지만, 실제 사용자/관리자의 경험을 구하는 근본적인 과제가 여전히 가장 큰 병목 현상이 될 가능성이 큽니다.
어쨌든, 이 주제를 시작했을 때보다 Discourse의 미래에 대해 더 희망적입니다. (절망적이었던 것은 아니지만, 약간 우려스러웠던 정도입니다 
)