بہترین self-hosted Trello متبادل کا موازنہ

کون سا self-hosted Trello متبادل منتخب کرنا چاہیے؟

تین self-hosted Trello متبادل آپ کے وقت کے مستحق ہیں: اگر آپ Trello کا عین board اور اس کی import file چاہتے ہیں تو Planka، جب کسی ٹیم کو single sign-on اور صرف board سے زیادہ سہولیات درکار ہوں تو Vikunja، اور جب VPS (virtual private server) محدود وسائل کا ہو تو Kanboard منتخب کریں۔ Focalboard پر نیا project شروع نہ کریں۔ اس کے standalone server میں 783 دن سے کوئی release نہیں ہوئی، اور اس کی README اب maintainer طلب کرتی ہے۔

Wekan یہاں موجود 5 tools میں پانچواں ہے۔ یہ کام کرتا ہے، لیکن اس کی memory کی ضرورت باقی تمام tools کے مجموعے سے کئی گنا زیادہ ہے۔ ذیل میں دیے گئے ہر version، licence اور date کی 5 August 2026 کو جانچ کی گئی تھی۔

ہر board tool کو کتنی RAM درکار ہوتی ہے؟

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

یہ تازہ installation کے بعد، کسی صارف کے استعمال کے بغیر، عام idle figures ہیں۔ یہ وہی قسم کی قدر ہے جسے stack شروع ہونے کے ایک منٹ بعد docker stats رپورٹ کرتا ہے۔ منصوبہ بندی کے لیے ان اعداد کو استعمال کریں، پھر اپنے سسٹم کی پیمائش کریں۔ درست megabyte سے زیادہ مجموعی انداز اہم ہے۔

Kanboard کم از کم 70 MB استعمال کرتا ہے، کیونکہ یہ PHP اور SQLite پر مبنی ہے۔ کوئی طویل عرصے تک چلنے والا application process آپ کے boards کو memory میں نہیں رکھتا، اس لیے requests کے درمیان container تقریباً کچھ بھی memory استعمال نہیں کرتا۔ Vikunja 110 MB استعمال کرتا ہے۔ یہ ایک single Go binary ہے اور SQLite اس کا default database ہے، اس لیے ایک ہی container پوری stack پر مشتمل ہوتا ہے۔ Planka کو 280 MB درکار ہوتی ہے، کیونکہ یہ ہمیشہ دو containers پر مشتمل ہوتا ہے: ایک Node server اور PostgreSQL۔ Planka میں SQLite کا اختیار نہیں ہے، اس لیے database کو تبدیل نہیں کیا جا سکتا۔

Wekan 750 MB استعمال کرتا ہے، کیونکہ یہ Meteor application ہے۔ Meteor، Node memory میں live query layer برقرار رکھتا ہے اور ہر board کی تبدیلی WebSocket کے ذریعے ہر کھلے browser کو بھیجتا ہے۔ اس لیے اس کی memory connected لوگوں کی تعداد کے ساتھ بڑھتی ہے، مستقل نہیں رہتی۔ 1 GB VPS پر Wekan شروع تو ہو جاتا ہے، لیکن چند لوگ بڑا board کھولیں تو پہلی مرتبہ ہی بند ہو جاتا ہے۔ اس کی علامت ایسا container ہے جو غائب ہو کر exit code 137 کے ساتھ دوبارہ شروع ہوتا ہے۔ docker compose ps اسے restart loop کے طور پر دکھاتا ہے۔ host پر dmesg -T | grep -i "out of memory" کے ذریعے اس کی تصدیق کریں، کیونکہ kernel کا out-of-memory killer application کو کوئی اطلاع نہیں دیتا۔

Database dependency آپ کے backup کے تقریباً نصف کام کا تعین کرتی ہے، اس لیے ہر tool کی تفصیل ایک سطر میں یہ ہے۔ Planka کے لیے PostgreSQL ضروری ہے۔ Vikunja کا default database SQLite ہے، اور یہ PostgreSQL اور MySQL یا MariaDB کو بھی استعمال کر سکتا ہے۔ Kanboard کا default database SQLite ہے، اور یہ MySQL، MariaDB اور PostgreSQL کو بھی استعمال کر سکتا ہے۔ اس کی documentation PostgreSQL کی سفارش کرتی ہے اور NFS (network file system) پر SQLite استعمال کرنے سے خبردار کرتی ہے۔ Focalboard کا default database SQLite ہے۔ Wekan، MongoDB wire protocol استعمال کرتا ہے۔ اس کی موجودہ default Compose file حقیقی MongoDB server کے بجائے embedded SQLite backend کے ساتھ FerretDB v1 فراہم کرتی ہے۔ اگر آپ MongoDB استعمال کرنا چاہتے ہیں تو الگ MongoDB 7 Compose file موجود ہے۔

ان میں سے کون سے projects کی maintenance اب بھی جاری ہے؟

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard اس فہرست میں نمایاں استثنا ہے، کیونکہ اس کی آخری release 783 دن پہلے ہوئی تھی۔ اس کی آخری standalone release، v8.0.0، June 2024 کی ہے۔ Mattermost نے boards کی development ایک الگ repository میں موجود plugin میں منتقل کر دی، اور standalone README میں لکھا ہے کہ repository کی maintenance فی الحال نہیں ہو رہی۔ اس موازنے میں یہ واحد واضح "نہیں" ہے۔ باقی تمام projects میں کچھ نہ کچھ trade-off موجود ہے۔

Planka کی 109 دن پرانی release اس project کے لیے مناسب ہے جو سال میں چند releases جاری کرتا ہے۔ Version 2.1.1 April 2026 کی ہے۔ Kanboard نے check سے 12 دن پہلے v1.2.53 جاری کی، اور اس سے پہلے کی دو releases March اور April 2026 میں جاری ہوئی تھیں۔

Vikunja اور Wekan دونوں نے check کے ایک دن کے اندر release جاری کی، لیکن ان دونوں حقائق کو مختلف انداز میں سمجھنا چاہیے۔ Vikunja نے v2.5.0 کو معمول کی minor release کے طور پر tag کیا۔ Wekan نے اسی دن v10.65، v10.66 اور v10.67 tags جاری کیے، جو اس کا معمول کا release cadence ہے۔ Frequent releases کا مطلب stable target نہیں ہوتا۔ Wekan کے ساتھ آپ تیزی سے بدلتے version number کو track کرنے کا انتخاب کرتے ہیں، اس لیے tag کو pin کریں اور ہر bump سے پہلے release notes پڑھیں۔

کیا آپ کو صرف ایک بورڈ سے زیادہ کچھ ملتا ہے؟

زیادہ تر تقابلی مضامین صرف یہ کہتے ہیں کہ "یہ Trello جیسا دکھائی دیتا ہے"۔ یہ پہلو RAM سے بھی زیادہ اہم ہے، کیونکہ deadline والی ہر چیز کے لیے board موزوں نہیں ہوتا۔

• Planka صرف board tool ہے، اور کچھ نہیں: projects، boards، lists، cards، labels، checklists، comments اور attachments۔ August 2026 تک Calendar اور map views صرف Pro features ہیں۔
• Vikunja ایک ہی task set کے لیے چار views فراہم کرتا ہے: List، Kanban، Table اور Gantt۔ ہر task صرف ایک بار موجود ہوتا ہے، اور اسے duplicate کرنے کے بجائے view تبدیل کیا جاتا ہے۔
• Kanboard میں work-in-progress limits، subtasks، attachments، comments، automatic actions اور filtering کے لیے ایک چھوٹی query language کے ساتھ boards شامل ہیں۔ اس کے اپنے homepage پر لکھا ہے: "The number of features is voluntarily limited"۔ یہ ایک مناسب وضاحت ہے۔
• Wekan میں swimlanes والے boards کے ساتھ checklists، custom fields، REST (representational state transfer) API اور webhooks شامل ہیں۔
• Focalboard نے انہی cards کے لیے board، table اور calendar views فراہم کیے تھے۔ اسے مکمل فہرست کے لیے یہاں شامل کیا گیا ہے۔

اگر آپ دراصل کچھ task tracking کے ساتھ wiki چاہتے ہیں تو یہ درست تقابل نہیں ہے۔ BookStack، Wiki.js اور Outline اس نوعیت کا احاطہ کرتے ہیں، جبکہ self-hosted Notion کے متبادل all-in-one workspace کا احاطہ کرتے ہیں۔

متعدد صارفین کی رسائی اور single sign-on

Planka مفت Community edition میں OpenID Connect کو support کرتا ہے۔ اس کی official Compose file میں settings تبصروں کے طور پر شامل ہوتی ہیں، جن میں OIDC_ISSUER، OIDC_CLIENT_ID اور OIDC_CLIENT_SECRET بھی شامل ہیں، اس لیے upgrade کرنے کے بجائے صرف ان کے comments ہٹائیں۔ اپنی organisation سے باہر کے لوگوں کے لیے guest roles صرف Pro feature ہیں۔

Vikunja ایک وقت میں متعدد providers کے ساتھ OpenID Connect کو support کرتا ہے۔ VIKUNJA_AUTH_OPENID_ENABLED=true مقرر کریں، پھر ہر provider کے لیے VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* variables کا ایک block شامل کریں۔ اس میں teams اور ہر project کے لیے sharing بھی موجود ہے، جو بیس افراد کی organisation کی حقیقی ضرورت ہے۔

Wekan LDAP (lightweight directory access protocol)، OAuth2، OIDC اور SAML کو support کرتا ہے۔ Kanboard میں LDAP پہلے سے شامل ہے، جبکہ دیگر تمام صورتوں کے لیے generic OAuth2 plugin موجود ہے۔ اس کے علاوہ per-project roles اور groups بھی دستیاب ہیں۔ Focalboard کے standalone server میں single sign-on بالکل موجود نہیں، اس لیے اسے خارج کرنے کی یہ دوسری وجہ ہے۔

ان میں سے کسی کو بھی اپنے زیرِ انتظام چلنے والے Authentik identity provider کے ساتھ مربوط کیا جا سکتا ہے۔ عموماً یہ ہر ایپ کے لیے بیس افراد کو الگ password دینے سے بہتر طریقہ ہے۔

کیا آپ اپنے Trello boards درآمد کر سکتے ہیں؟

Planka میں یہ عمل سب سے آسان ہے۔ Trello سے board کو JSON کے طور پر export کریں، Planka میں board بنائیں، پھر Import پر click کریں اور Trello منتخب کریں۔ پہلے حدود پڑھیں، کیونکہ یہ حقیقی حدود ہیں: users اور attachments درآمد نہیں ہوتے، ہر card سے صرف ایک checklist منتقل ہوتی ہے، اور Trello کا default JSON export بغیر کسی warning کے 1,000 actions پر رک جاتا ہے اور یہ نہیں بتاتا کہ data truncate ہو گیا ہے۔ نتیجے پر اعتماد کرنے سے پہلے file خود check کریں۔

Vikunja میں درآمد Trello کے OAuth flow کے ذریعے ہوتی ہے۔ Settings کھولیں، پھر "Import from other services" منتخب کریں۔ ہر migrator کے icon کے ظاہر ہونے سے پہلے اسے config میں enable کرنا ضروری ہے، اور VIKUNJA_SERVICE_PUBLICURL درست ہونا چاہیے، کیونکہ OAuth redirect server سے نہیں بلکہ آپ کے browser میں ہوتا ہے۔ Vikunja، Todoist، Microsoft To Do، TickTick اور Wekan سے بھی data درآمد کرتا ہے۔

Wekan اپنے import form میں paste کیے گئے Trello board JSON کو قبول کرتا ہے۔ Kanboard میں Trello importer built-in نہیں ہے۔ اگر آپ کے پاس Trello کی کئی سالہ history منتقل کرنے کے لیے ہے تو اسے چھوڑنے کی بنیادی وجہ یہی ہے۔

موبائل تجربہ کیسا ہے؟

پانچوں میں صرف Vikunja کی official mobile apps موجود ہیں۔ Android اور iOS builds ہر release کے ساتھ جاری ہوتے ہیں، اور app repository خود کو alpha قرار دیتا ہے۔ اس لیے اسے web interface کے متبادل مرکزی طریقے کے بجائے معاون interface سمجھیں۔ Planka کے project کی طرف سے کوئی official app موجود نہیں، تاہم اس کا web interface responsive ہے اور third-party clients دستیاب ہیں۔ Wekan اور Kanboard صرف web پر دستیاب ہیں، جبکہ Kanboard کا interface واضح طور پر desktop screen کے لیے بنایا گیا ہے۔

لائسنس کا سوال، اور Planka مختلف کیوں ہے

Planka اب open source نہیں رہا، اور زیادہ تر تقابل میں یہی حقیقت شامل نہیں کی جاتی۔ اس کا آغاز MIT کے تحت ہوا، 2023 میں یہ AGPL-3.0 پر منتقل ہوا، اور 2.0 series سے یہ PLANKA Community License کے تحت جاری ہوتا ہے۔ یہ fair-code لائسنس PLANKA Software GmbH کے پاس ہے۔ GitHub اس کے لائسنس کو "Other" دکھاتا ہے، کیونکہ یہ لائسنس OSI سے منظور شدہ نہیں ہے۔ اپنی ٹیم کے لیے اسے self-host کرنا مفت ہے اور اس کی واضح اجازت ہے۔ اس میں ذاتی، داخلی، non-profit اور تعلیمی استعمال شامل ہیں۔ اس تک رسائی دوبارہ فروخت کرنے یا اسے دوسری کمپنیوں کے لیے service کے طور پر چلانے کے لیے commercial licence درکار ہے۔

دو افراد کے لیے یہ ایک مناسب شرط ہے۔ کمپنی کے لیے ضروری ہے کہ اس شرط کو پہلے پڑھ لیا جائے، اس سے پہلے کہ بیس افراد کا کام اس میں شامل ہو۔ باقی چار عام open source پروجیکٹس ہیں: Vikunja AGPL-3.0 کے تحت، Wekan اور Kanboard MIT کے تحت، جبکہ Focalboard Apache 2.0 اور AGPL-3.0 کے امتزاج کے تحت دستیاب ہیں۔

دو منتخب آپشنز کے لیے pinned Compose فائلیں

Image tag کو pin کریں۔ latest کا مطلب ہے کہ اگلا docker compose pull آپ کو major version کے درمیان منتقل کر سکتا ہے، اور major versions ایسی database migrations چلاتے ہیں جنہیں آسانی سے واپس نہیں کیا جا سکتا۔ ذیل کی دونوں فائلیں upstream فائلیں ہیں، جن میں tag کو حقیقی release پر مقرر کیا گیا ہے۔

SQLite پر Vikunja، ایک container:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

پہلے data directory کو درست owner کے ساتھ بنائیں، کیونکہ container UID 1000 کے طور پر چلتا ہے اور root-owned directory میں نہیں لکھ سکتا:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

صحت مند stack میں service کی حالت running دکھائی دیتی ہے، اور info endpoint ایسا JSON واپس کرتا ہے جس میں version field شامل ہوتی ہے۔ یہاں connection refused کا مطلب ہے کہ container exit ہو چکا ہے۔ docker compose logs vikunja وجہ بتاتا ہے، اور database file پر permission error عام وجہ ہے۔

PostgreSQL پر Planka، دو containers:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust کا مطلب ہے کہ PostgreSQL کسی بھی connection کو password کے بغیر قبول کرتا ہے۔ یہ صرف اس لیے محفوظ ہے کہ database port host پر publish نہیں کیا گیا، اس لیے اس تک رسائی حاصل کرنے والی واحد چیز اسی Compose network پر موجود دوسرا container ہے۔ postgres service میں ports: entry شامل نہ کریں۔

کسی بھی stack کو براہ راست internet کے سامنے نہیں ہونا چاہیے۔ دونوں 127.0.0.1 پر bind ہوتے ہیں، اس لیے ان کے سامنے reverse proxy رکھیں اور TLS (transport layer security) وہیں terminate کریں۔ جب آپ ایک سے زیادہ سروسز host کریں تو متعدد Compose ایپس کے سامنے Traefik عموماً یہی طریقہ ہے، اور Docker Compose basics گائیڈ ان فائلوں کے ان حصوں کی وضاحت کرتی ہے جنہیں یہ صفحہ چھوڑ دیتا ہے۔

آپ کا board ایک database ہے، اس لیے اس کا backup لیں

board کا tool خاموشی سے fail ہو سکتا ہے۔ کسی volume کے ختم ہونے تک کسی کو missing backup کا پتا نہیں چلتا، اور damaged SQLite file بظاہر معمول کے مطابق کھلتی ہے، پھر database disk image is malformed ہفتے بعد error دکھاتی ہے۔

Live SQLite file کو cp کے ذریعے کبھی copy نہ کریں۔ Copy کے دوران write جاری ہو سکتی ہے، اس لیے archive مکمل دکھائی دے گا، لیکن restore کے بعد database میں کچھ rows موجود نہیں ہوں گی۔ Copy مکمل ہونے میں جتنے چند seconds لگتے ہیں، اتنی دیر کے لیے service روک دیں:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Planka کے لیے running PostgreSQL cluster کی data directory copy کرنے کے بجائے PostgreSQL dump لیں، اور uploads volume الگ سے محفوظ کریں، کیونکہ attachments database میں موجود نہیں ہوتے:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls اصل volume name دکھاتا ہے۔ یہ Compose project name کے بعد _data پر مشتمل ہوتا ہے۔ ایسا name دینے سے جو موجود نہیں ہے، ایک empty volume بن جاتا ہے اور بغیر کسی error کے ایک درست مگر empty archive تیار ہو جاتا ہے۔ اس لیے بعد میں file کا size ضرور چیک کریں۔

پھر اسی box پر ایک scratch stack میں اسے ایک بار restore کریں اور وہ card کھولیں جو آپ کو یاد ہو۔ ایسا backup جسے آپ نے کبھی restore نہ کیا ہو، صرف ایک اندازہ ہے۔ Archives کو server سے باہر بھی بھیجیں، کیونکہ جس VPS کو آپ محفوظ کر رہے ہیں اسی پر رکھی ہوئی copy backup نہیں ہوتی۔ VPS سے restic backups میں اس عمل کا دوسرا حصہ بیان کیا گیا ہے۔

دو سفارش

2 GB VPS پر 2 افراد کے لیے: Planka چلائیں۔ ظاہری شکل اور طریقۂ کار کے لحاظ سے یہ Trello سے سب سے زیادہ مشابہ ہے، Trello import ایک ایسی file ہے جسے آپ drag کرکے شامل کرتے ہیں، اور 280 MB idle memory کی وجہ سے 2 GB میں سے زیادہ تر memory reverse proxy اور آپ کی میزبانی کردہ دیگر سروسز کے لیے خالی رہتی ہے۔ Community License دو افراد کی internal team کے لیے بلا معاوضہ کافی ہے۔ اگر آپ source-available license پر انحصار نہیں کرنا چاہتے تو اسی server پر 110 MB کے ساتھ SQLite استعمال کرنے والا Vikunja open-source انتخاب ہے۔

کسی organization میں 20 افراد کے لیے: PostgreSQL پر Vikunja چلائیں۔ اس حجم پر 20 local passwords کے بجائے OpenID Connect درکار ہوتا ہے، teams اور per-project sharing درکار ہوتی ہے، اور زیادہ تر کام board پر موزوں نہیں ہوگا؛ اس لیے List، Table اور Gantt views محض اضافی سہولت نہیں رہتیں۔ AGPL-3.0 کی وجہ سے team کا حجم بڑھنے پر license کے بارے میں الگ گفتگو بھی نہیں کرنی پڑتی۔ اسے SQLite کے بجائے PostgreSQL دیں، reverse proxy کے پیچھے رکھیں، اور روزانہ کا dump اس server کے علاوہ کسی اور جگہ محفوظ کریں۔

اگر server میں 1 GB سے کم RAM ہو تو دونوں میں سے کوئی بھی جواب موزوں نہیں ہے۔ 70 MB کے ساتھ Kanboard استعمال کریں، یہ قبول کریں کہ Trello cards دوبارہ درج کرنا ہوں گے، اور بچائی ہوئی memory کو 2026 کے لیے self-hosting کی مختصر فہرست میں سے کسی اور مقصد پر استعمال کریں۔ آپ جو بھی tool منتخب کریں، اس کی مکمل installation الگ guide میں ہونی چاہیے۔ یہ page صرف انتخاب کے بارے میں ہے۔

FAQ

کون سا self-hosted Trello متبادل کم ترین RAM استعمال کرتا ہے؟

Kanboard تقریباً 70 MB idle استعمال کرتا ہے، کیونکہ یہ SQLite کے ساتھ PHP پر مبنی ہے اور requests کے درمیان memory میں کچھ محفوظ نہیں رکھتا۔ اس کے بعد Vikunja آتا ہے، جو single Go binary کے طور پر تقریباً 110 MB استعمال کرتا ہے۔ Wekan سب سے زیادہ memory استعمال کرتا ہے، یعنی تقریباً 750 MB، کیونکہ Meteor ہر connected browser کے لیے Node memory میں live query layer برقرار رکھتا ہے۔ Stack کے idle ہونے کے بعد اپنی instance کی memory استعمال `docker stats` سے measure کریں، کیونکہ یہ عام اعداد ہیں، ضمانت نہیں۔

کیا میں اپنے Trello boards کو self-hosted tool میں import کر سکتا ہوں؟

Planka اور Wekan دونوں Trello کا JSON board export براہِ راست قبول کرتے ہیں۔ Vikunja، Trello کے OAuth flow کے ذریعے import کرتا ہے، اور interface میں ظاہر ہونے سے پہلے config میں migrator کو enable کرنا ضروری ہے۔ Kanboard میں built-in importer نہیں ہے۔ دو حدود کو پیش نظر رکھیں: Planka users یا attachments import نہیں کرتا اور ہر card کے لیے صرف ایک checklist سنبھالتا ہے؛ نیز Trello کا default JSON export آپ کو اطلاع دیے بغیر 1,000 actions پر رک جاتا ہے۔

کیا Focalboard اب بھی 2026 میں اچھا انتخاب ہے؟

نہیں۔ آخری standalone release، v8.0.0، June 2024 کی ہے۔ یہ اس comparison کی 5 August 2026 کو جانچ کے وقت 783 دن پرانی تھی، اور README کے مطابق repository فی الحال maintained نہیں ہے۔ Mattermost نے board development صرف ایک الگ repository میں plugin کے طور پر جاری رکھی، اس لیے جس server کو آپ self-host کریں گے، development اسی حصے میں رک چکی ہے۔ اس کے بجائے Planka یا Vikunja منتخب کریں۔

کیا Planka اب بھی open source ہے؟

OSI کی تعریف کے مطابق نہیں۔ Planka پہلے MIT تھا، 2023 میں AGPL-3.0 پر منتقل ہوا، اور version 2.0 سے PLANKA Community License کے تحت release ہوتا ہے۔ Personal، internal، non-profit اور educational استعمال کے لیے self-hosting مفت ہے۔ Access resell کرنے یا اسے third parties کے لیے service کے طور پر چلانے کے لیے commercial licence درکار ہے، جبکہ calendar view، guest roles اور recurring cards Pro tier میں شامل ہیں۔ اگر OSI-approved licence لازمی ہے تو Vikunja AGPL-3.0 ہے اور Kanboard MIT ہے۔

کیا مجھے PostgreSQL درکار ہے، یا SQLite کافی ہے؟

Vikunja، Kanboard اور Focalboard default طور پر SQLite استعمال کرتے ہیں، جو ایک server پر چند users کے لیے کافی ہے۔ Planka کے لیے PostgreSQL لازمی ہے اور یہ SQLite کا option نہیں دیتا۔ جب بیک وقت کئی users write کریں تو PostgreSQL پر منتقل ہو جائیں، کیونکہ SQLite writes کو serialise کرتا ہے اور مصروف instance `database is locked` واپس کرنا شروع کر دیتی ہے۔ SQLite file کو network share پر بھی نہ رکھیں: Kanboard کی documentation اسی وجہ سے NFS پر SQLite استعمال کرنے سے منع کرتی ہے۔