Run by the operators who use it
Managed service providers solve the same problems in parallel, separately, and usually at eleven at night. The BIASHARA community exists so that work is shared: the scripts that hold up, the detections worth keeping, and the deployment notes that save a weekend.
The answer usually exists, in somebody else's console
The problems that consume a service desk are rarely unique. A mail profile that will not reconnect, a patch ring that needs to respect a factory shift, a detection that fires every time the accounts team logs in from a hotel. Somewhere, another provider has already solved it properly, tested it on a fleet and learned where it goes wrong.
Vendor support channels are not built to carry that kind of knowledge. They are built to triage faults in the vendor's product, which is a different job. So the operational knowledge stays locked inside individual businesses, and every provider pays again to learn the same lesson.
The community is the deliberate alternative. It is small, practical and made up of people with the same responsibilities: a shared script library, a channel where the question gets a real answer, and written notes from the providers who went first.
Membership is for people who run managed services and for the engineers who build the platform. There is no sales floor, no lead capture and no vendor booth.
Shared automation arrives with its parameters, its verification step and a note about where it has been run. If it has not been tested, it is labeled as untested.
Members often serve the same regions and sectors. Sharing the plumbing has not cost anyone a client, because the service is the differentiator, not the disk cleanup script.
Three places, each with a job
Chat for the question you have right now. A shared repository for code that should outlive the conversation. A knowledge hub for the things that deserve to be written down properly.
- ChannelMonitoring and scriptingPatch rings, maintenance windows, agent behaviour on awkward builds, and the scripts that survived a real fleet.
- ChannelDetections and responseTuning security events so the alert that matters is not buried under fifty that do not, and what to do when it fires.
- ChannelSelf-hostingTopology, sizing, upgrades, backups and the questions worth answering before a go-live weekend.
- ChannelService desk practiceQueue design, service level targets, escalation and the automation boundaries members are comfortable with.
- RunbooksClient onboarding and offboardingThe full sequence written as automation, from account creation to device enrollment to the handover document.
- ScriptsEveryday remediationDisk cleanups, service restarts, profile repairs and update repairs, each with the verification step included.
- DetectionsSecurity rules worth keepingRules contributed with their false positive notes, so you inherit the tuning along with the detection.
- BaselinesPolicy starting pointsIdentity, access, network and device policies that members have already defended in a client audit.
- GuidesDeployment, end to endStanding the platform up on-premises, in the cloud and across both, including what to check afterwards.
- PlaybooksRunning the service deskDesigning targets and queues a small team can honor, and tuning the triage agent for your client base.
- Field notesMigrations, as they happenedHonest write-ups of moving off a licensed stack, including the parts that took longer than planned.
- ReferenceModule documentationHow each module is configured, what the endpoint agent collects, and how the extension points work.
How the roadmap actually gets set
A roadmap written behind closed doors tends to serve whoever paid the most. This one is written where members can see it, argue with it and watch what happens to their proposal.
- 01Proposals come from the work
- Anyone running the platform can propose a change, with the case made in terms of the operational problem it solves rather than the feature it adds. Proposals are public from the moment they are filed.
- 02Priority follows operational weight
- Members say what a problem costs them in hours, risk or client trust. A request that three providers can describe concretely moves ahead of one that sounds impressive in a demonstration.
- 03Decisions are recorded with reasons
- Accepted, deferred and rejected proposals all get an explanation. Knowing why something was declined is more useful than discovering six months later that it was quietly dropped.
- 04Releases are predictable and documented
- Each release says what changed, what to check after upgrading and what is deprecated. Members running production estates get warning rather than surprises.
- 05Disagreement is normal
- Providers serve different sectors and will not always want the same thing. Where a need is genuinely specific, the answer is usually an extension point rather than a setting nobody else understands.
Four ways in, none of them onerous
Most members start by reading, and that is a perfectly good contribution. The useful habit is writing down the thing you just worked out, while you still remember why it was hard.
-
01
Join and listen
Ask for an invitation, read the channels relevant to your estate, and borrow freely from the shared library. Nobody is counting your messages.
-
02
Answer one question
If you have solved something another member is wrestling with, say so. The answer takes five minutes and saves someone an evening.
-
03
Contribute what works
Share a script, a detection or a runbook with its parameters and verification step. Mark it tested or untested honestly and the review process does the rest.
-
04
Propose a change
File the operational problem you keep hitting. Describe the cost, the workaround and what a fix would let you stop doing by hand.
Short, and enforced
The community works because the rules are few and applied consistently. They exist to protect two things: the client data members are responsible for, and the willingness of busy people to keep answering questions.
Moderation is handled by members and by the platform team together. Breaches are dealt with directly rather than debated in public, and a member who repeatedly ignores them loses access.
- Never post client data. Redact hostnames, addresses, names and anything identifiable before you share a log.
- Label untested code as untested. Someone will run it on a production fleet.
- Share credentials with nobody, including other members and anyone claiming to be the platform team.
- Keep commercial pitches out of the channels. Recruiting and vendor promotion belong elsewhere.
- Disclose security issues to the platform team before discussing them publicly.
- Assume the person asking is competent and busy. Answer the question before improving the architecture.
- Respect the license on anything you contribute, and do not publish an employer's code without permission.
Join the operators already running it
Tell us a little about your service desk and we will send an invitation to the community along with the repository and the deployment documentation.