Skip to content
Vinxi/Kernel THE BOOK OF RECORD

SmartInventory 3.0 — Customer Forks Analysis

Purpose: Characterize what the per-customer forks of the legacy product actually contain, and distill the configurability requirements the new Lepton Infrastructure Cloud must ship so that no customer ever needs a code fork again.

Method: A branch-taxonomy scout over all ~1,626 branches produced a customer roster; seven read-only deep-dive agents then profiled the live, materially-diverged forks via git diff/git show against origin/develop (no checkouts). The BharatNet/NCC/HFCL set was analyzed as one family (they are one trunk + per-state snapshots). Companion docs: SmartInventory_Legacy_Architecture_Study.md, SmartInventory_Product_Specification.md, SmartInventory_Gaps_and_Improvement_Analysis.md.

Date: 2026-06-16. Caveat: Real domain logic lives in PostgreSQL fn_* procs whose bodies are not in the repo; migration scripts are partial (deployed via an out-of-repo “Deployment Manager”). Branch state is the source of truth only for application code, not the live DB.

1. Headline findings

  1. The branch count is a mirage. Of ~1,626 branches, >85% are generic feature/personal/release branches. There are ~19 real customers, and only ~11 live + materially diverged. The rest are abandoned (often 0–2 commits genuinely ahead of develop).

  2. “Branch-per-customer” massively overstates the real fork surface. The biggest “family” — BharatNet + NCC (MP/UK/Uttarakhand/NER2) + HFCL Punjab — is effectively ONE fork (develop-bharatnet trunk) plus near-identical per-state release snapshots that each add only 3–50 unique commits. So six “customer branches” ≈ one customer codebase.

  3. Forks fall on a spectrum from pure-config to deep-domain, but almost all of it is config-shaped: every deep-dive concluded the fork would collapse to runtime configuration on a properly designed multi-tenant platform — with only a handful of genuinely custom pieces (railtrack-corridor routing, an FTP storage pipeline, some OFN planning maths).

  4. Two platform primitives would eliminate the overwhelming majority of all forking:

    • (A) A runtime custom-entity / dynamic-form / attribute-schema builder. Every substantial fork adds entity types (ACT: CX/GX; Airtel: HUB/SubBox/EndBox/CSA/DSA/SubArea; RailTel: railway POP model; Dialog: PEP + Tower→Site; BharatNet: Depth/RedLine + FDC/FPOI/GP roles). ACT went so far as to rebuild the dynamic-form engine themselves — proof customers will pay enormous cost to get this if the platform lacks it.
    • (B) A declarative integration/connector framework. Airtel’s ZTE+Huawei+ESB+OID+OPSWAT (~46k lines), RailTel’s OSS/NMS sync + dual IdP, Dialog’s MIFE+SAP+Azure+FCM are all “configure a provider,” yet today are bespoke forked code.

  5. Most fork volume isn’t customization at all — it’s (a) generic bugfixes staged on customer branches instead of develop (Syokinet), (b) removal of half-finished generic POCs (IshaniTech, Airtel both delete the old PM-Tools integration), and (c) carried-along trunk churn from stale merge-bases. The process is as much the problem as the architecture.

  6. Recurring, serious security leakage across forks (see §5): committed cloud service-account keys (Dialog FCM, NCC_MP GCS), plaintext DB/SFTP creds in every branch’s config, an [AllowAnonymous] splicing dashboard (Dialog), commented-out [Authorize] (Airtel ESB) — on top of the mainline backdoors/hardcoded-AES found in the gaps analysis.

  7. Three candidate vertical accelerators emerge from the forks: a BharatNet government survey/HOTO/acceptance vertical, an OFN/backbone planning capability (Dialog), and a vendor-EMS reconciliation capability (Airtel ZTE/Huawei).

2. Customer roster & coverage

CustomerIdentityCanonical refDivergence (files / +ins)Ahead/BehindDeep-dived?
BharatNetGovt of India rural broadbanddevelop-bharatnet1052 / +157k1378 / 166✅ (family)
NCC (MP/UK/Uttarakhand/NER2)NCC Ltd — BharatNet state EPChotfix-NCC_MP-Prod-8.28.2_1 etc.up to 1113 / +164kup to 1428 / 166✅ (family)
HFCL PunjabHFCL — BharatNet Punjab EPChotfix-HFCL_Punjab-Prod-8.27.2993 / +145k1250 / 166✅ (family)
DialogDialog Axiata — Sri Lanka telcodevelop-dailog-new1590 / +257k1131 / 866✅
ACTACT Fibernet — Bengaluru ISPdevelop-ACT451 / +98k648 / 4✅
RailTelRailTel — Indian Railways PSUdevelop-Railtel348 / +45k294 / 40✅
Airtel (Africa)Bharti Airtel — Nigeria FTTH/FWAdevelop-airtel319 / +46k150 / 44✅
IshaniTechIntegrator partner, Indiadevelop-IshaniTech110 / +4k53 / 40✅
Syokinet/YyokiFTTH ISP, Kenyadevelop-syokinet-new38 / +1.7k45 / 4✅
TeraSoftIntegratorTeraSoft-Prod-8.18.2-hotfix512 / +15k210 / 166⏸ frozen mid-2025
RVNL UPE/UPWRail Vikas Nigam — railway PSURVNL_UPE-Prod-8.18.4-hotfix~530 / +30k~300 / 166⏸ frozen mid-2025
WefolgOSS-integration, AfricaWefolg_8.13.7.2_Drop2485 / +26k30 / 310❌ abandoned Jan-2025
SafaricomKenya telcodevelop-safaricom1879 / +165k172 / 1656❌ abandoned Mar-2024
Vodafone Idea (Vi)India telcorelease-vi-v8.8.91346 / +66k2 / 1461❌ abandoned May-2024
BahonISP, Bangladeshbahon_issues_develop_prod568 / +33k0 / 411❌ superseded
VGG / AsiaFibernet / Airlink / OnitelMisc ISPsvarioussmall~0–2 ahead❌ trivial/dead
SpaceWorld / Microscan / Jhansi-RailwayISP / integrator / railway POCvariousrecent commits on old basefar behind❌ borderline, low-value

Deep-dived: the 7 live forks above. Abandoned/frozen customers were intentionally skipped (no silent omission) — their forks predate large develop evolution and carry little unique live value; revisit only if a specific customer re-activates.

3. Per-customer fork profiles (condensed)

3.1 Syokinet / Yyoki (Kenya) — minimum viable customization

  • Adds: nothing structural. 4 layers hidden (layer_details.isvisible=false), 2 ROW report-column labels, one action disabled, a DB name + map path in Web.config, an integration toggle re-enabled, and ROW-authority reference data (Indian municipality names — likely copy-paste cruft).
  • The rest of its +1.7k lines are genuine bugfixes (splicing port status, microduct no_of_ways persistence, PDF null-guards) that belong on develop.
  • Config verdict: tenant-distinguishing surface is 100% config. The fork exists mainly as a bugfix staging branch.

3.2 IshaniTech (India integrator) — light, mostly re-use + removal

  • Adds: re-mounts the existing additional-attributes/dynamic-form tab onto more entities; cable bulk-update with an “acquire-from” rule; a per-request serviceability buffer/entity_type; a 2FA ticket approval (already gated by a global_settings flag). Most line-delta is deleting the generic PM-Tools POC + whitespace churn.
  • Only genuinely custom code: an FTP dual-storage file pipeline (~850 lines) with a hardcoded SHAPE/TAB/DXF/KML folder taxonomy.
  • Config verdict: ~all config except the storage pipeline → storage backend must be a config-selectable provider (local/FTP/S3).

3.3 Syokinet & IshaniTech together establish the floor: a well-designed platform reduces a customer to config + upstreamed bugfixes.

3.4 RailTel (Indian Railways PSU) — deep domain + OSS/NMS

  • Custom model: railway POP attribute set (~40 cols: zone/division/circle/station, DG/battery/AC power inventory, rack & equipment counts) via an IRailtelAttribute mixin; railtrack-following fiber routing (fn_get_nearest_railtrackroute, pgRouting along track ROW, buffer setting); a project/work-order traceability layer (activity_id/project_id/planning_id/workorder_id) threaded through 9 asset tables; a built-out FiberLink circuit layer (dark fiber/bandwidth/DWDM).
  • Integrations: two IdPs — Authentik (OIDC) for app/mobile login, Keycloak for machine-to-machine; an OSS/NMS sync ETL (NelLocationToTempPod, ~2,900 lines) pulling from RailTel NOC APIs into oss_* staging then merging; NMSIntegrationController exposing topology to RailTel’s NMS. reCAPTCHA (present, commented out).
  • Config verdict: ~90% absorbable (custom-attribute builder, FiberLink-as-core, pluggable OIDC, OSS-connector framework, report builder, managed migrations). Genuinely custom: railtrack-corridor routing — which generalizes to a pluggable “snap-to-linear-reference” routing strategy (rail/road/utility corridor).

3.5 ACT (Bengaluru ISP) — the customer rebuilt the platform’s missing primitive

  • Custom model: two new entity types CX/GX (full att_details_*/item_template_*/views/BL/DA scaffold); layer_details extended with is_dynamic_attribute_enable/dynamic_attribute_table.
  • Centerpiece: ACT replaced the hardcoded per-entity Razor forms with a runtime EAV dynamic-form platform — a 5-table attribute stack (osp_attribute_def/_value/_section_config/_dependency + equipment parallel), a 5,591-line BLOSPDynamicForm engine, a generic _AddOSPDynamic.cshtml renderer for ~20 entity types, and two new Admin config UIs (OSP-CFG/EQP-CFG module trees) to add/hide fields at runtime. Plus a naming-nomenclature engine (configurable patterns, geometry-driven region resolution, auto-ID generation) and auto-generated wide report views (trigger rebuilds view on attribute-def change).
  • Also: a 9,186-line MobileFormController + 5,687-line POP room/rack visual editor — a full webview mobile field-ops app (GPS/QR/photo/offline cache).
  • Config verdict: ACT’s 648-commit divergence is overwhelmingly what a configurable platform absorbs natively. Lesson: ship the custom-entity/dynamic-form builder as a first-class primitive, or customers rebuild it at huge cost.

3.6 BharatNet / NCC / HFCL family — one fork + per-state snapshots = a vertical

  • Structure: a linear chain off the develop-bharatnet trunk; per-state members (UK/NER2/Uttarakhand/MP/Punjab) add only 3–50 unique commits. The 100k+ shared delta is the real artifact.
  • Shared delta = a BharatNet government survey/acceptance vertical: an ~8,800-line SurveyReportController (Survey/HOTO/Optical-HOTO/Route-HOTO/L14/SLD/BOQ/DGPS/MB-Sheet acceptance reports with government fields), offline field-survey APIs, new Depth/RedLine entities, BharatNet domain roles (FDC/FPOI/RI/GP/CPE) overlaid on generic tables, region-templated reports (_MP/_UK/_UPE method proliferation + Excel-UK/L14-PDF-UK module flags), per-circle DB connections, pgRouting auto-planning.
  • Per-member unique (tiny): Uttarakhand = central-SSO token format; HFCL = RTK-GPS base-station pooling; NCC_MP = a pluggable storage abstraction (GCS/NAS/FTP/Local — with a committed GCS key); NER2 = the RedLine entity.
  • Config verdict: collapses to zero forks with (1) custom-entity builder, (2) report-template builder with per-region definitions as data, (3) per-tenant config (DB/endpoints/storage/auth/flags). The survey/HOTO delta is a strong packaged “BharatNet accelerator” candidate.

3.7 Dialog (Sri Lanka telco) — core refactor + OFN planning, deep proc logic

  • Custom model: Tower→Site/CO refactor (att_details_pod extended with SL telco/admin columns: province/district/depot/ds_division/tx_type/technology/ring/solution_type…); new PEP entity; many domain tables (backbone_plan_*, site_award_details, core_planner_*, ring_details, top_routes).
  • Features: BackBone Planning, Core Planner, Common Path Finder, Ring Topology/SLD, Site Awarding + item-vendor costing, an [AllowAnonymous] Splicing Monitoring Dashboard. Pervasive province/region row-level access.
  • Integrations: Dialog MIFE OSS gateway (OAuth2), SAP ERP (hardcoded notification_source_system="SAP"), Azure AD/Entra SSO, Firebase FCM push (committed key, receiver_fcm_key="test" bug).
  • Hardest to absorb: 595 CREATE FUNCTION definitions — the planning/rules logic lives almost entirely in opaque DB procs. ⚠️ 22-month rebase debt; in-place edits to shared controllers → merge conflicts.
  • Config verdict: entity refactor → custom-entity builder; planning subsystems → feature-flagged platform features + a configurable planning/rules engine (the genuinely hard part); costing → connector; geo-access → configurable geo-hierarchy + RLS; integrations → connector framework + secret store; terminology → runtime i18n override.

3.8 Airtel (Africa / Nigeria) — new entity hierarchy + connector suite

  • Custom model: a 7-type access hierarchy — HUB / SubBox / EndBox (point boxes) + CSA / DSA / SubArea (polygon service areas with home-pass counts, nested Area→SubArea→DSA→CSA), SubArea = the FTTx POP boundary with OLT binding + deployment-status lifecycle. Full forked table/BL/DA/view/uploader stack per type.
  • Integrations (the headline, ~46k lines):
    • ZTE & Huawei EMS ingestion — two modern (DI/async/Serilog) console schedulers, identical pattern: watch source (folder/FTP ZIP) → validate → stage (*_staging_*) → DB-validate → migrate to entities → auto-splice → archive → track run.
    • ESB OSS/BSS API — /serviceability, /portreservation, /changeport, /portutilization (nearest splitter/ODF within buffers, FTTH/FWA feasibility, road distance via Google Directions, atomic port reserve/release); PortReleaseScheduler frees expired reservations.
    • Airtel-OID OIDC SSO (AUUID claim mapping); OPSWAT MetaDefender upload scanning (blocks infected files before storage); Africa egress proxy + TLS-1.2 hardening.
  • Config verdict: the single strongest argument for the PRD’s two flagship primitives — runtime entity builder (the box/area hierarchy) + declarative connector framework (ZTE/Huawei/ESB/OID/OPSWAT are all “configure a provider”). Serviceability/port-reservation should be platform-native capabilities (the PRD’s graph + spatial core subsumes fn_get_nearby_*).

4. Cross-cutting customization taxonomy → required platform primitives

Every customization observed across all 7 forks, mapped to the platform capability that makes it config instead of code:

#Customization dimensionSeen inRequired platform primitive
1New entity types & attributes (CX/GX, HUB/Box/CSA/DSA, PEP, Depth/RedLine, railway POP, FDC/FPOI/GP)ACT, Airtel, Dialog, RailTel, BharatNetRuntime custom-entity / attribute-schema builder (typed attrs, point/line/polygon geometry, parent-child topology rules, roll-ups, map layer + icon) — no enum/class/.map/migration edits
2Dynamic forms (field show/hide/require, sections, conditional dependencies, autofill)ACT (rebuilt it), IshaniTech, BharatNetConfig-driven form builder with a dependency/rules engine, auto-rendered for every entity from metadata
3Naming / numbering schemes (per-region patterns, auto-IDs)ACT, BharatNetPer-tenant naming-rule engine (mask grammar, geometry-driven region resolution, ID generation, uniqueness validation)
4Reports (HOTO/L14/SLD/BOQ/survey; per-region variants; wide views)BharatNet (heavy), RailTel, Dialog, allReport/template builder — report definitions (columns, scope, format Excel/KML/Shp/PDF/SLD) as data, region = a row not a _MP method
5OSS/BSS, EMS & ERP integrations (ZTE/Huawei ingest, ESB, MIFE, SAP, NMS sync)Airtel, RailTel, DialogDeclarative integration/connector framework (source, format/column mapping, target entity mapping, schedule, post-process, auth) — providers as config profiles + an ETL/staging→validate→merge pipeline
6Identity / SSO (Airtel-OID, Authentik, Keycloak, Azure AD, central-token)Airtel, RailTel, Dialog, BharatNetPluggable IdP/OIDC connector (URLs + client creds + external-id claim mapping as config)
7Push / notification / messaging (FCM, SMS gateways)Dialog, BharatNetNotification connector (provider-pluggable) + secret store
8File storage backends (GCS/NAS/FTP/Local, FTP dual-store)NCC_MP, IshaniTechConfig-selectable storage provider (local/FTP/S3/GCS/blob) as platform middleware
9Upload security scanning (OPSWAT)AirtelConfigurable upload-pipeline hook (AV/CDR provider-pluggable)
10Serviceability / feasibility / port reservationAirtel, RailTel, BharatNetPlatform-native spatial+graph capability (nearest-element, buffers, FTTH/FWA coverage, atomic port reserve/release as background jobs)
11Network/OFN planning (backbone, core planner, ring, auto-plan, snap-to-track routing)Dialog, RailTel, BharatNetConfigurable planning/rules engine + pluggable routing strategies (incl. snap-to-linear-reference) — hardest to generalize
12Feature on/off (layers, modules, menu items, 2FA, encrypted-query)every forkPer-tenant feature-flag + module registry (not schema columns toggled by migration)
13Geo hierarchy & row-level access (province/region/circle scoping)Dialog, RailTel, BharatNetConfigurable geo-hierarchy + row-level security
14Branding / white-label (logo, client name, terminology)every fork (already mostly config)Theming + runtime i18n/terminology override (already partly solved via global_settings)
15Per-tenant DB / endpoints / schema (per-circle DBs, per-region hosts)BharatNet, RailTel, Airtel, allPer-tenant config + schema isolation + managed versioned migrations
16Mobile field-ops (dynamic forms on mobile, rack/room visualizer, offline)ACT (heavy), BharatNetShared mobile module driven by the same entity/form config (not re-forked per customer)

Bottom line: primitives #1, #2, #4, #5, #12, #15 together would absorb the vast majority of every fork analyzed. #11 (planning/rules) is the residual genuinely-hard frontier.

5. Recurring security findings across forks

These compound the mainline issues in SmartInventory_Gaps_and_Improvement_Analysis.md (auth backdoors, hardcoded AES key, SQLi). Per-fork:

  • Committed cloud service-account keys: FCMCredentials.json (Dialog), GCS service-account JSON (NCC_MP). These are live credential leaks in git history across many branches.
  • Plaintext DB / SFTP / API credentials in every fork’s Web.config / App.config / appsettings.json / datashare.inc.
  • [AllowAnonymous] Splicing Monitoring Dashboard (Dialog SpxI49FtzController) — unauthenticated network data exposure.
  • [Authorize] commented out on Airtel’s ESBController (OSS/BSS provisioning API).
  • Shared dev DBs across tenants (IshaniTech’s datashare.inc points at Safaricom_Dev) — tenant data-isolation smell.

Recommendation: treat the committed service-account keys and backdoors as an incident to remediate in the live product now (rotate keys, purge from history, close backdoors), independent of the rewrite. The new platform must mandate a secret manager and forbid credentials in source.

6. Process & branching findings

  • No re-baselining discipline: merge-bases span 2024–2026; Safaricom is 1,656 commits behind develop, Dialog 866 behind (22-month debt). Forks rot.
  • Bugfixes are staged on customer branches (Syokinet) instead of develop, so fixes don’t propagate to other tenants and inflate fork size.
  • Convention erosion: the canonical mainline is often a *-Prod-<ver> hotfix branch, not develop-<customer>; the develop- prefix is also misused for env-variants and personal branches. Customer identity must be parsed from suffix/region, not prefix.
  • Migrations are hand-applied dated SQL (no framework), per-tenant, partial-in-repo — the highest-risk fork driver and migration blocker.

Implication: even with a perfect multi-tenant architecture, the org needs single-codebase discipline (config-not-fork), a managed migration system, and CI that forbids secrets — otherwise the same sprawl recurs.

7. Candidate vertical accelerators (productize, don’t fork)

  1. BharatNet Government Survey/HOTO/Acceptance — the BharatNet family’s ~8,800-line survey-report suite + offline survey + DGPS/depth + L14/SLD/BOQ acceptance is a repeatable government-FTTx vertical. Package as a configurable accelerator (report templates + survey workflow + acceptance schema).
  2. OFN / Backbone Planning — Dialog’s backbone/core-planner/ring-topology subsystems generalize to a carrier OFN planning module.
  3. Vendor-EMS Reconciliation — Airtel’s ZTE/Huawei ingestion is a reusable “sync inventory from OLT/ODN vendor EMS” connector pattern (valuable to any large FTTH operator).

8. Open questions / needs the live DB

  • The bodies of the new fn_* procs across all forks (Dialog alone adds 595) — the actual planning/migration/serviceability logic is in the DB, not the repo. This is the #1 blocker for specifying primitives #5, #10, #11 precisely.
  • Exact layer_details flag values and item_template_* columns for the new entity types (CREATE rows partially in-repo).
  • Whether per-region DBs (airtelafrica_si_dev/_qa, per-circle BharatNet conn strings) reflect distinct multi-country deployments.
  • The precise auto-splicing / port-allocation rules embedded in Airtel/BharatNet migration SQL.
  • For frozen customers (TeraSoft, RVNL): whether they re-activate and need profiling.

Compiled 2026-06-16 from seven read-only branch deep-dives. This characterizes the per-customer divergence; pair with the architecture study (what the generic product is), the product specification (modules/features), and the gaps analysis (what to improve) to scope the new platform’s configurability requirements.