현 drupal 을 국산 오픈소스 프로그램으로 대체할까 합니다.

drupal의 어떤 부분에 만족하시는지 알면 그에 걸맞는 대체 프로젝트를 찾을 때 기준이 되겠습니다.

FOSS중심의 메타블로그 형태는 어떨까요?

CMS에 비해서 단점이 더 많을라나요?

돈들여 바꿨는데 얼마 지나지 않아서 바꾼다니 아쉽네요.

<- 이거면 안되는 게 없어~
정품 소프트웨어 사용 캠패인

드루팔 만한 게 없는 것 같은데요...

그냥 드루팔을 지금보다 더 개조화하여 한국사람에 맞는.... 또, 이곳 취지에 맞는...그렇게 운영을 하시는 게 낳다고 봅니다...
제가 전문가는 아닙니다만.....이것 저것 모두 설치 해 본사람중에 하나입니다.....

하지만, 제로보드보다는 그누보드가 훨씬 낫구요...(오로지 제 생각임)

역시 아직은 외국 오픈소스에 따라올 만한게 없는 것 같습니다....

아니면...예전처럼 phpbb......

많은 분들이 migration 후의 장애비스무리한 상황이 재현되는 것(문제는 짧지 않은 시간이 걸린다는 것이겠죠..)과, 익숙치 않은 UI 에 대한 반감(?)을 걱정하시는 것 같습니다.

제가 예전 drupal 로 migration 을 할 때도 적었던 것 같은데, 제 견해로는 현재 손을 대지 않고 KLDP 규모를 감당할 수 있는 프로그램은 없습니다. 많은 기능을 요구하면서 성능도 좋아야 하니까요. 즉 이런 구조라면 사용할 수 있는 것을 모두 동원하여 설계부터 들어가야 합니다.

그렇다면 KLDP 에서는 왜 이 작업을 시작하지 않을까요? 다들 아시다 시피 KLDP 에 전업으로 묶여있는 사람은 없습니다. 설령 전업으로 묶으려고 해도 원하지 않는 사람도 있을 것이고요.

순선님도 이 부분을 뼈저리게(?) 느끼고 계실 것이기 때문에 결국에는 이미 만들어져 있는 것을 이용하여 우리가 필요한 부분이나 문제가 되는 부분을 reporting 하고 개선되도록 하는 방향을 선택하신 것입니다.

drupal 의 경우 기능상이나 현재 성능상의 부분에서는 많은 분들의 도움과 인내로 현재는 상당히 좋아진 편이라 생각을 합니다. 하지만 이번의 경우에는 (국내에서 만들어진 application 을 선택하려는?) 현재 drupal 에 우리가 reporting 한 부분에 대한 반영이 제대로 되지를 않고, 많은 버그를 리포팅 했지만 개선이 거의 되지 않는 부분에 대한 한계를 느끼고 있기 때문입니다.

위에 순선님이 적었듯이, 또는 많은 분들이 patch 나 bug 를 제공하고 느껴보았을 그 가로막힌 벽같은 것들같이 왜 이 패치가 필요한지, 왜 이 버그가 빨리 고쳐져야 하는지에 대한 당위성 제공에 한계를 느끼기 때문입니다. 즉, native language 가 아닌 것의 한계일 수도 있을 겁니다.

또한, 저도 개발자로서 많은 패치나 request 를 받아 보았지만, 제게 당장 와 닿는 부분이 아니라면 외면하거나 또는 우선순위를 저 뒤로 밀려놓는 경우가 있습니다. 아마 다른 개발자들도 마찬가지라고 생각을 합니다. 그렇기 때문에 국내에서 만들어진 application 이라도 KLDP 의 유지보수에 참여를 하지 않는다면 외국산 application 을 사용하는 것과 별 다름이 없지 않을까 생각을 합니다. 순선님께서는 이 부분을 명심해야 할 것입니다.

솔직히 Zeroboard EX 나 gnuboard 또는 어떤 application 을 선택한다고 해도 drupal 보다 낫다는 보장을 할 수 없다고 생각합니다. 하지만, 안주하는 것은 Open Source 정신과는 맞지 않다고 생각합니다. KLDP 의 트러블 슈팅을 할때, 여러분들께서 짧게 올려 주시는 글에서도 가끔은 "왜 이걸 생각못했지?" 하면서 배울 때가 많습니다. 또한, 저 또는 KLDP 에 대한 마이그레이션이나 트러블 슈팅을 하시는 분들도 문제 해결 후에는 꼭 reporting 을 하려고 합니다. 이 리포트가 여러분들에게 간접 경험이 될 수 있기 때문입니다. 이런 것이 KLDP 를 찾아와 주시는 분들에 대한 저희의 보답이며, 또한 이러한 직접 경험과 간접 경험에 의하여 Open Source 가 더 발전할 수 있다고 저는 생각을 합니다.

제로보드가 현시점에서는 가장 적절한 대안 같아 보입니다.

가장 KLDP에 근접한 구현 예제는 Widesoccer 이곳입니다.

Blog와 리플에 대한 답글이 지원되지 않는 것을 제외하고는 거의 이곳과 매우 비슷합니다.
(기능이 없다기 보다는 기능을 사용하지 않는 것으로 보입니다.)

개인적으로는 PHPBB로 회귀하거나 혹은 /.가 같은 weblog도 시도해볼만 하지 않은가 생각해 봅니다.

There is no spoon. Neo from the Matrix 1999.

일단 특정 솔루션만 두고 생각하는게 아니라는걸 감안해두고 생각해보자면, 아예 그냥 KLDP에서의 원활한 사용을 위한 게시판 툴을 제작하거나, 혹은 적절한 게시판 툴을 선택 후 해당 툴을 KLDP.net 내에서 계속적으로 개발, 관리해 나가는것이 뭔가 가장 이상적인 형태가 아닐까 라는 생각을 해 봅니다.

만일 지금의 drupal 시스템같이 upstream에 적용하는것이 어느정도 제한적으로 작용할 수 밖에 없다면, 아예 KLDP/국내 전용으로 내부적인 개발 방향을 전환해버리고, 해당 프로그램의 새로운 Tree로서 발전할 수 있는 가능성도 있지 않겠느냐는 것이지요. 그것이 오픈소스의 장점 중 하나이니까요. ^^ 이를테면 기존의 drupal에 KLDP 최적화 및 한글화 작업이 적용된 새로운 드루팔 계열 Tree로 발전한다거나 하는식이 되겠지요.

물론 뭐 제로보드라던지 기타 다른 툴들의 사용 가능성을 배제하자는것은 아닙니다. 좀 더 좋은 툴이 있고, 좀 더 개선하고 발전해 나갈 여지가 있다면 다른 툴의 도입도 충분히 고려해야겠지요.

　
########### 기운이 솟아나는 티거 호랑이 노래 ###########
폴짝폴짝 폴짝폴짝 비켜나세요. 티거가 나가거든요 폴짝폴짝폴짝~
저기가는 저 푸우 조심하세요~ 바지벗고 다니다가 어흥!!

킴스보드 http://www.shsolution.co.kr/kimson/home/shsolution/

강력추천합니다. ^^

그럼 이참에 디비도 큐브리드로. ㅎㅎㅎ

솔직히 한국산 툴이라 하더라도, 수정사항이 제대로 반영이 되는가 하는데에선 부정적입니다.

아무리 한국산 툴이라도 버그리포팅을 해도 제대로 안 먹힐때가 많았습니다. 특히 하위 호완성에서 충돌이 나는 경우(스키마 수정이라던지.)
라이센스 문제로 배포하지 말라던지.(제가 그문제로 예전 태터툴즈 0.9 에서 워프로 바꿨습니다. 그후 GPL로 바뀌었어도, 첫인상이 않좋아서.)
그런 상황에서 무조건 한국산 툴만 쓰자 하는건 저로서는 황당하기 그지 없는 말입니다. 차라리 개발이 활발하고, 리포팅이 잘 받아들여지는 툴을 쓰자하면 찬성했을 겁니다. 그런데, 그런건 알아보지도 않고 무작정 한국산 툴! 만 고집한다면 이것역시 안주하기만 하는것 아닙니까.

프로그램을 직접 만들어 쓰는 것도 좋습니다, 그리고 직접 제작이 아니더라도 리포팅을 통해 개선한다 해도 찬성입니다. 하지만 무조건 한국!
이런건 동의할 수 없습니다.

제가 많은 웹 소프트웨어를 사용해 보지 못해서
추천은 못하겠지만, 개인적으로는 새로운 것에 관심이 많기 때문에 찬성합니다.

오픈소스가 실험정신이 강한 면이 있어서 발전도 하고 하는것이니,
그 정신에도 어느정도 맞는것 같습니다. :-)

그리고, 국산을 쓰신다는것도 찬성이고요.

KLDP같은 싸이트에서 국산 프로그램을 쓴다면,
개발자분도 힘이나서 더 발전할 수 있을것 같다는 생각이 드는군요.

어쨌든 phpBB에서 drupal로 옴기면서 힘드셨던 생각에 쉽게 나온 얘기는 아닐거라 생각합니다.

KLDP를 위해 노력하시는 분들께 감사를 드립니다. :-)

---


Jabber: lum0320@jabber.org

gnome.or.kr에서 쓰고 있는데...
추천 안합니다=3=3=333

----
the smile has left your eyes...

Metabbs의 경우, 1.0대에서는 구조가 많이 바뀔거라고 하긴 하는데... 어쨌든, 아예 KLDP를 목표로 놓고 개발하는 것도 방법이 아닐까요? KLDP 정도의 사이트라면, 여기에 사용하는 것을 목표로 개발할만한 동기는 될 것도 같습니다. 아니면 KLDP의 고수 분들이 Metabbs 개발에 참여해서 영향력을 행사하는 것도 나쁘지 않을 것 같습니다...

http://lordmiss.com DDD, BMDRC

제가 관리자라면 fork하니 어쩌니 고민할 필요없이 그냥 지금 있는 그대로의 KLDP를 오픈소스 프로젝트로 만들어 버리겠습니다. KLDP의 문제점을 고치고 기능을 추가하려는데 왜 번거롭게 Drupal이 수정되기를 기다리며 Drupal 사용자가 늘어나길 기다려야 할까요? KLDP처럼 개발 능력에 있어서 훌륭한 사용자 집단을 가지고 있는 사이트가 굳이 오픈소스 가져다 쓰는 수준에 머무를 필요가 있을까요? 오픈소스를 주제로 삼는 사이트가 그 관리에 있어 오픈소스 모델을 도입하는 건 무척이나 자연스러운 일이라고 생각합니다.

현재 당면한 문제는 다른게 아니라 관리 인력 부족이라는 사실에는 모두 공감하실거라 믿습니다. 보수 없는 일에 많은 시간과 노력을 투자할 수 있는 사람이 적은 건 당연한 일입니다. 대신 짬짬이 생기는 시간에 작은 노력을 투자할 수 있는 사람은 많습니다. 동기만 충분하다면 말이죠. 그리고 제가 보기에 KLDP에는 그 짬짬이 생기는 시간과 작은 노력을 투자할만한 동기를 가진 사용자는 많이 있다고 느껴집니다. 사이트 자체를 오픈소스 모델로 가지고 가자는 얘기는 사이트 개선에 관한 관리자의 부담을 이러한 사용자와 나누자는 얘깁니다. KLDP 사용자가 KLDP의 문제점을 발견했을 때 필요한 것은 KLDP의 소스이지 Drupal의 소스가 아닙니다. KLDP의 문제점을 해소하기 위해 Drupal의 소스를 뒤져야 한다는 건 동기를 뛰어넘는 노력을 요구하지 않을까요?

만일 KLDP의 소스가 공개되어 있다면 다음과 같은 가상의 시나리오도 상상해 볼 수 있습니다.

한 사용자가 점심시간에 회사에서 자신의 댓글을 수정하다 보니 포인트가 깎이는 버그를 발견했습니다. kldp.net으로 가서 kldp 프로젝트의 cvs 트리를 훑어보고는 대충 문제점이 어디인지 감을 잡은 그는, 좀더 자세히 살펴보기 위해 퇴근 후 집에 있는 데스크탑에 kldp의 소스를 받고는 전용 에디터와 유틸리티의 도움을 받아 코드를 조사합니다. 자신이 고칠 수 있다고 판단이 선 그는 자신의 데스크탑에서 kldp 서버를 돌리기 위한 패키지를 다운받아 설정하고 실행환경을 꾸밉니다. 몇 차례의 코드 수정과 테스트를 거치고 문제가 해결된 듯 하자 kldp.org에 자신이 발견한 문제점과 해결법을 올리고 공유기 포트를 열어 외부에서 자신이 수정한 kldp 서버에 접속하여 사람들이 테스트 할 수 있도록 합니다. kldp.org에 올라온 글을 보고 그 수정된 kldp 서버에 접속하게 된 사람들은 공지 사항으로 올라와 있는 좀더 자세한 보고서를 읽을 수 있으며 그 임시 서버의 여러 게시판에 글을 작성하거나 수정하기도 하면서 다양한 테스트를 진행해 볼 수도 있고, 또 테스트 결과와 새로운 발견 및 해결책을 그곳에 바로 글로 적어 남길 수 있습니다. 다양한 피드백을 받은 그 사용자는 재검토후 좀더 나은 해결책을 가지고 다시 kldp.org에 패치와 보고서를 남기게 되고, kldp.org의 관리자는 kldp 프로젝트 cvs 메인에 패치를 반영하고 다음 시스템 리셋때 실제로 새로운 버전의 코드를 반영하여 서버를 재실행 시킵니다.

물론 가상의 시나리오 입니다만, 핵심은 사용자가 문제를 해결하는데 필요한 자료와 프로그램들을 오픈소스 모델을 통해 자연스럽게 구할 수 있었다는 점입니다. 그리고 이런 오픈소스 모델에서는 관리자가 해야할 일이 바로 사용자가 저런 일들을 자연스럽게 할 수 있도록 환경을 구축하고 유지시켜주는 것이 되겠죠.

이런 오픈소스 모델로 인해 관리자의 부담이 반드시 줄어든다고 장담은 못하겠습니다만, 한가지 확실한 건 능동적이며 개발 능력을 갖춘 사용자가 작은 부담으로 남 눈치 보지않고 자유롭게 참여할 수 있는 길이 생긴다는 점입니다. 그렇다면 문제는 이러한 사용자들이 KLDP에 실제로 많은가 하는 것인데, 여러분들은 어떻게 생각하십니까? 제 대답은 위에 적었듯이 Yes 입니다.