질문하신 경쟁사들에 대해서는 잘 모르겠지만, 디스코urses를 설정하면서 느낀 점은 사이트 안에 꽤 많은 콘텐츠가 쌓여야 비로소 그 장점이 가장 잘 드러나고 다른 사람들에게 보여주기 가장 쉽다는 것입니다. 이는 온보딩을 어렵게 만듭니다. 왜냐하면 저처럼 ‘진짜’ 커뮤니티 포럼의 잠재적 이점을 아는 사람이 다른 사람들에게 디스코urses가 어떤지 보여주기 위해 더 많은 노력을 해야 하기 때문입니다.
동료들에게 디스코urses 사용을 설득하려다 보니, 우리가 만들고 싶은 것과 비슷한 다른 커뮤니티를 찾기가 힘들었습니다. 이는 우리의 사용이 대부분 내부적이기 때문이기도 하지만, 기존 사용자층이 꽤 니치(niche)하기 때문이기도 합니다. 제가 이전에 접했던 가장 좋은 예는 스탠(Stan) 포럼이었지만, 동료들과 공유하기에는 기술적인 내용이 너무 많았습니다. 디스코urses가 실제로 어떻게 활용되고 있는지에 대한 더 좋은 예시를 제공하면 도움이 될 것입니다(링크만 주는 것이 아니라, 디스코urses가 왜 훌륭한지를 보여주는 좋은 스레드에 대한 심층 링크를 제공하며 직접 검토해 주는 것 말입니다).
또 다른 선택지로는, 정말 큰 규모의 대중적 커뮤니티를 대상으로 저가 요금을 제시해 손실 리더(loss leader) 전략으로 유치해 보는 것도 있을 수 있습니다. 예를 들어, 우리 중 많은 사람이 스택 익스체인지(Stack Exchange) 소프트웨어에 익숙했기 때문에 거의 구매할 뻔했습니다(다만, 모든 콘텐츠 형식에 대해 QA 포맷이 가장 적합한 것은 아니었습니다).
참고로, meta.discourse는 오픈소스/커뮤니티 매니아를 제외한 다른 사람들에게는 좋은 홍보재가 아닙니다(그들에게는 매우 매력적이지만요). 일반인들에게 매력적으로 보이기에는 너무 세세하고 지엽적인 내용들이 많습니다.
물론 제품 자체의 문제는 아닙니다. 디스코urses는 정말 훌륭합니다!
다만, 그 부분에서는 try.discourse.org를 더 잘 활용할 수 있을 것 같다고 생각합니다. 몇 분 전에 문서(그리고 그 사용법)에 대한 다른 주제에서 이미 ‘WIP’ 카드를 꺼내 썼고, 연달아 두 번 사용하니 스트레스성 두통이 올 정도입니다 하지만, 다양한 기능의 예시가 실제로 구현된 인터랙티브한 ‘설명’ 사이트를 만들면 이 문제를 해결하는 데 정말 도움이 될 것이라고 생각합니다.
나는 담론(Discourse)의 잠재력에 분명히 관심이 있으며, mighty라는 플랫폼에 대해서도 인지하고 있습니다. 이 플랫폼에서는 그룹, 서클, haaartland 등을 관리한 경험이 있습니다.
어떤 이유에서인지, 의사결정을 위한 트레이드오프를 판단하는 데 도움이 될 것이라고 생각하는 모든 정보를 찾는 데 어려움을 겪었습니다. 담론뿐 아니라 다른 플랫폼들도 마찬가지입니다.
JD, 당신이 알다시피 저는 컨웨이 법칙을 강하게 지지합니다.
담론에도 이 법칙의 양상이 드러납니다. 예를 들어, 코딩 호러(Coding Horrors)의 서명(署名) 있는 게시물에 대한 회피 경향은 다른 포럼과 이곳의 기본 가이드에서 그 모습을 드러내며, 토픽에 여러 개의 답글을 보내되 답글들을 하나의 게시물로 통합하지 말라는 메시지 역시 마찬가지입니다.
더 깊은 수준에서 보면, 개발 팀의 철학적 또는 문화적 정합성이 소프트웨어를 결정합니다. 예를 들어 mighty는 자신들을 나무 꼭대기에 위치시키고, 모든 커뮤니티를 하위(서브)로 배치했으며, mighty 앱은 사용자가 관련성이나 관심사에 맞는 커뮤니티를 검색할 수 있도록 허용합니다.
또한 대부분의 사람들은 여러 플랫폼에 대해 동등한 지식을 갖추고 있지 않아, 제대로 정보를 바탕으로 선택을 내리기 어렵습니다. 따라서 기술적 고려 사항은 광고에 의해 완화되며, 많은 플랫폼이 '눈에 띄는 웹사이트’를 갖추고 있습니다. 소프트웨어를 설치하거나 재빌드할 필요 없이 켜고 끌 수 있는 옵션이 많은데, 담론은 테마와 같은 컴포넌트들로 향하는 경향이 있습니다. 이는 개발자나 테크니컬한 소프트웨어 관리자에게는 매력적일 수 있지만, 수수료를 내고 바로 사용하려는 상업적 조직이나, 페이팔, 스트라이프, 글로벌 세금 등 완전한 통합을 통해 커뮤니티를 유료로 제한(게이트)하려는 사람들에게는 그렇지 않을 수 있습니다.
이것은 단순히 '용도에 맞는 말(마치 말과 경주에 적합한 말)'의 문제만은 아니지만, 그 점은 매우 중요하며 동시에 충분하지도 않습니다.
맞아 - 하지만 이런 것을 평가하거나 누군가에게 가능성을 시연할 때 가장 먼저 하고 싶은 것은 실제 사용 모습을 보는 거야… 판매용 홍보 문구를 읽는 게 아니라. (적어도 나는 그렇게 하고 싶어). 메타가 그렇게 되어야 한다는 건 아니야, 그냥 그 니치를 채우지 못하고 있다는 거지.
하지만 데모 사이트는 마치 취미 프로젝트처럼 보이게 합니다 … phpbb가 그랬던 것처럼요. '기능’은 보여줄 수 있지만, 이 모든 기능이 만들어내는 가치는 보여주지 못합니다.
넓게 접근 가능한 주제에 대한 몇몇 활발한 Reddit이나 FB 그룹을 유치해 보면, Discourse가 커뮤니티를 어떻게 향상시키는지 더 좋은 예시를 보여줄 수 있지 않을까요? 수혜를 입을 수 있는 대형 포럼의 주요 모더레이터 몇 명에게 접근해 보는 데는 큰 비용이 들지 않을 것 같습니다.
참고로, 동료들에게 보여주기 위해 찾은 최고의 예시는 drownedinsound였습니다 — 하지만 그것은 아마도 제 상사와 부서 내 다른 몇몇 사람들이 새로운 음악에 관심이 있기 때문일 것입니다. 육아/스포츠/영화와 같은 보다 폭넓은 호소력을 가진 주제의 예시를 찾아보거나 타겟팅해 보는 것은 어떨까요?
저는 그 정도가 지나치다고 생각합니다. Docker 설치가 있긴 하지만, 설정 과정이 훨씬 더 쉬울 수 있다고 봅니다. 저는 다양한 사이드 프로젝트의 DevOps를 담당하는 데 꽤 경험이 있지만, 직접 호스팅을 해본 경험으로 인해 이 과정이 의도적으로 방해받고 있는 것처럼 느껴졌습니다. 이메일 설정은 어렵고 설정 파일을 직접 다뤄야 했으며, 플러그인도 마찬가지였습니다. 이 모든 것들은 관리자 UI에서 처리할 수 있어야 합니다. 참고로, 호스팅 서비스를 유도하기 위해 일부 기능을 비공개로 유지하고 싶다면 이해합니다. 하지만 직접 호스팅 경험의 매끄러움이 부족해, 이것이 공식적으로 권장되지 않는 옵션이고 언젠가 사라질지도 모른다는 우려를 하게 만들었습니다.
SMTP-as-a-서비스를 제공하고 직접 호스팅을 원하지 않는 사람들을 위해 1클릭 설치기를 설정해 줄 수 있는 VPS 제공업체로 리퍼럴을 통해 수익을 올리는 것이 가능할까요? 이렇게 하면 진입 장벽을 크게 낮출 수 있겠지만, 호스팅 서비스 매출을 잠식할 수도 있겠다는 생각이 듭니다.
CDCK에 대한 이점은 이를 통해 제공되는 광범위한 테스트(eyes-on testing)와 코드 및 기능 요청에 대한 추가적인 기여입니다.
어떤 부분이 '어렵다’고 하는 것인가요?
자신의 플랫폼에서 무언가를 호스팅하기 위해 필요한 최소한의 노력과 헌신에는 한계가 있다고 생각합니다. 또한 모든 것이 버튼 클릭만으로 해결된다면, 그들은 어떻게 자신의 웹사이트를 지원할 수 있겠습니까? 분명히 CDCK은 그 책임은 분리해야 합니다. 개인적인 참여를 통해든, 계약으로 다른 전문가(SME)의 직접적인 관여를 통해든, 장기적인 지원을 위해 필요한 지식을 갖추고 있거나 습득할 의지가 있다는 것을 기대하는 것은 합리적입니다.
몇 번 해보면, ‘기본’ 사양으로 완전히 새롭고 100% 독립적이며 완전히 소유한 사이트를 설정하는 데 20분이 채 걸리지 않습니다 - 도메인 구매까지 포함해서 말이죠. 정말 놀랍지 않나요?
개인적으로 플랫폼의 "예시 공개(surfacing examples)"에 대한 귀하의 의견이 더 공평한 지적이라고 생각합니다.
메타에서 어떤 사용자가 디스코urs 포럼의 기본 공개 문자열인 “This is a Civilized Place for Public Discussion” 문장을 검색하는 방법을 사용했던 것으로 기억합니다. 다른 언어에서도 작동하며, 다른 언어의 문자열도 검색할 수 있습니다.
디스코르스(Discourse)의 문제와 디스코르스가 실제로 해결할 수 없는 문제를 구분하는 데 주의가 필요하다고 생각합니다. 이메일 설정은 번거로운 작업이지만, 이메일을 발송하는 포럼을 운영해 온 수년간의 경험으로 볼 때 가장 큰 문제는 포럼 소프트웨어가 아니라 이메일 자체에 있습니다. 악용을 방지하기 위해 이메일 환경이 매우 엄격하게 통제되고 있어, 아웃바운드 이메일 환경을 설정하는 데 드는 시간과 노력은 디스코르스 이메일 설정에 필요한 짧은 시간에 비해 훨씬 큽니다.
이메일을 위해 도메인을 설정하고 DNS, SPF, DKIM, 발송 제한, 필터링, 블랙리스트 회피 등을 처리하는 것이 진정한 고통이지, 메일을 발송하기 위해 디스코르스에서 해야 할 몇 가지 설정은 그와 비교하면 아무것도 아닙니다. 도메인 관련 설정을 할 수 있다면 디스코르스 설정은 비교할 수 없을 정도로 쉬울 것이며, 반대로 디스코르스의 설정 부분조차 처리하지 못한다면 디스코르스와 무관한 이메일 설정에서 큰 어려움을 겪게 될 가능성이 높습니다.
비판적으로 들렸다면 죄송합니다. 사실 이 과정이 '어렵다’고 생각하지는 않는데, 아마도 관련 문서가 이 메타 사이트 여기저기에 흩어져 있어서일 겁니다. 그리고 이전에 레일스(Rails) 앱을 설치해 본 경험이 없다면, 상당한 수준의 전제 지식이 필요할 수 있습니다. 저는 이전에 파이썬(특히 Django) 관련 작업을 많이 해 봤는데, 런타임 설정으로 처리할 수 있는 것들을 위해 설정 파일을 수정하고 재컴파일하는 과정은 다소 이례적으로 느껴졌습니다.
결국 더 선호하지 않는 옵션처럼 느껴졌지만, 무료였기 때문에 수용한 것입니다.
여기서 사람들이 디스코urs UI를 평가하는 문제와도 약간 유사합니다. 우리 모두 이 UI를 좋아하고 익숙합니다. 하지만 작년에 제 학생들이 처음 사용해 보는 모습을 지켜보는 것이 흥미로웠습니다… 그들은 항상 쉽다고 느끼지는 않았고, 일부(모두는 아니지만)는 이를 “말이 많고” 혼란스럽다고 표현했습니다. 대부분은 결국 좋아했지만, 온보딩 과정은 이 유형의 커뮤니티에 익숙한 사람들을 더 잘 겨냥하고 있었습니다.
어쨌든 - 예를 들어 새로운 DigitalOcean 드롭렛에 설치하는 과정에 대한 커뮤니티 문서 작성에 도움을 드릴 수 있습니다. 이메일 설정을 위한 최적의 방법에 대한 가이드도 도움이 될 것 같습니다. 수신(inbound) 관련 설정은 복잡하고 문서화가 잘 되어 있지 않은 부분이 많습니다. 좋은 기본 설정을 제안하는 것이 합리적일 것입니다.
이메일이 골치 아픈 문제(종종 정당한 이유에서)라는 점은 사실이지만, ‘권장 경로’(예: “Sendgrid를 사용하세요” 또는 “SES를 이렇게 설정하세요”)에 대한 가이드를 제공할 수 없을 정도로 어렵지는 않습니다.
제 경우의 문제는 MS/365가 레거시 인증(Legacy Authentication) 사용을 극도로 꺼리기 때문에 더 복잡해졌습니다. 이것이 다른 조직에서도 문제가 될 가능성이 높다고 생각하지만, 확신은 없습니다. (참고로, 우리는 레거시 인증을 유지하기 위해 특별 면제를 받아야 했으며, 여전히 정책 변경 한 번으로 모든 것이 다시 멈출까 봐 불안합니다. 또한 수천 명 규모의 거대 조직에서 상대적으로 작은 1,500명 그룹의 사이트를 운영하고 있기 때문에 항상 우선순위가 높지는 않습니다.)
마찬가지로, 365와 SSO를 설정하는 과정도 기억하기로는 문서화가 잘 되어 있지 않았고, 아직 직접 시도해 보지 않았습니다 — 하지만 정말로 이를 원하고 있습니다. 다음에 올 사람을 위해 비틀린 칼을 베어 물고 가이드를 작성해야 할 것 같습니다.
하지만, 다양한 기능의 예시가 실제로 구현된 인터랙티브한 ‘설명’ 사이트를 만들면 이 문제를 해결하는 데 정말 도움이 될 것이라고 생각합니다.