day 2 of Ubucon Kenya leaned a little different from day 1. fewer infra-heavy walkthroughs, more talks about building, breaking, and belonging. by the end of it, the running theme was clear: the Ubuntu community in Kenya is figuring out how to grow the people alongside the projects.

bridging native C++ infrastructure with distributed data platforms

speakers: Irfan M. Ghat, Rodgers W. Simiyu, Paul Sanga Nyamawi

the trio opened day 2 with a deep dive into spark-connect-cpp, a C++ client for Apache Spark that uses Spark Connect's decoupled client-server model to let native systems talk to Spark without dragging the JVM (Java Virtual Machine) along for the ride. their argument is simple: if you want a Raspberry Pi or a factory sensor to push data into Spark, you should not need a full Java install to do it. spark-connect-cpp uses gRPC for transport, Protobuf for serialization, and Apache Arrow for zero-copy data transfer, which together give you low-latency, high-throughput communication suitable for real-time trading systems, edge devices, and scientific workloads.

Paul handled the security analysis section, and it was easily one of the most rigorous segments of the conference. he walked through the standard recon-to-remediation pipeline (checksec, rabin2, objdump, fuzzing with structured inputs, memory layout reasoning) and showed that the binary ships with NX, stack canaries, PIE (Position Independent Executable), and full RELRO (Relocation Read-Only). fuzzing with large structured CSV payloads did not produce a crash, which suggests the parsing path has solid bounds checks. his closing point was the right one: absence of evidence is not evidence of absence, and an open-source project benefits from adversarial collaboration.

a strong opener. C++ developers who have wanted Spark access without the JVM tax finally have a credible path forward, and the project is open to contributors on builds, releases, and security review.

Ubuntu local communities (LoCos and Circles)

speakers: Mauro Gaspari (in spirit), Sharon Koech

Sharon delivered this one on behalf of Mauro, walking the room through what Ubuntu LoCos and Circles actually are and how anyone in the room could start their own. the framing was practical: Ubuntu's strength has always been the community layer around the distro, and LoCos are the formal mechanism that lets local groups organize meetups, share knowledge, and contribute back to the broader Ubuntu ecosystem.

she also covered the Ubuntu Summit Extended program, which lets local communities host satellite events tied to the main Ubuntu Summit, and the lightning talk submission process for remote contributors who cannot travel. the call to action was direct: create your LoCo, host your Summit Extended, submit your lightning talk. there is a structure waiting for anyone willing to organize.

a fitting talk for a community-run conference. half the room probably went home thinking about whether their city needs a Circle.

the curious engineer

speaker: Duncan Njoroge (@guyfromtheke)

Duncan's second appearance of the conference (he opened day 1 with the cloud-init talk) was less technical and more philosophical. the entire talk revolved around one premise: curiosity is your unfair advantage. tools change, technologies change, frameworks come and go, but the engineer who keeps asking "what does this button do?" is the one who stays relevant.

he framed it as the H/T (head-to-toe) problem solver mindset, leaning on Jay Yang's "you can just do things" as the operating principle, and closed with a simple ABC: always be curious. go build. go contribute. go create. it was short, punchy, and the kind of talk you needed in the middle of a long conference day.

Duncan has a knack for these. the cloud-init talk on day 1 had immediate practical takeaways, and this one was the energy reset everyone needed before the next technical block.

why most beginner apps are easy targets: securing beginner Django applications

speaker: Vincent Chiriba

Vincent's talk was aimed squarely at the developers shipping their first or second Django app, which is exactly the demographic that needs this talk the most. he covered three areas where beginner applications consistently fail in production. first, secret management: sensitive data does not belong in code, environment variables exist for a reason, and the worst place a secret can end up is a public GitHub repository. second, secure settings: DEBUG should never be true in production because it leaks internal system details, ALLOWED_HOSTS needs to be configured properly, and configuration should always be environment-driven. third, access control: not every authenticated user should reach every view, and Django's permissions and roles system exists so you do not have to invent your own.

the talk landed because it stayed concrete. these are the exact mistakes that show up in code reviews of junior developer projects, and they are the mistakes that turn into production incidents when those projects start getting real traffic. his closing point ("3" being the number to remember, referring to the three pillars he covered) was a clean mnemonic.

a useful talk to send to anyone who just deployed their first Django app to a VPS. small changes, big security wins.

powering digital growth with open source and Linux

speakers: Lucky Baraka, Ilyas Bourzat, Enock Kibet (Digibiashara)

Lucky opened with the Digibiashara story, a Mombasa-based digital agency built entirely on open source. the stack was the headline: Ubuntu Linux as the foundation, Docker and LXD for containerization, Juju and Kubernetes for orchestration, Python and Go for backend services, NATS for messaging, and Infisical for secrets management. zero licensing fees, zero vendor lock-in, and a fully transparent stack they can show to clients.

the most useful part of the talk was the AkiliHub case study, which walked through how the team built a full SaaS platform on this stack and the mistakes they made along the way. hardcoded secrets in git? fixed with Infisical. NATS misconfiguration causing data loss? solved with JetStream persistence and replay policies. no staging environment and testing on production? rebuilt the workflow with LXD snapshots and a proper staging-to-QA-to-prod pipeline. lessons like "start with Docker from day 1" and "NATS beats REST for internal service comms" came directly from production scars, which is the kind of advice you cannot find in a tutorial.

the transparency about the mistakes was the standout for me. most agency pitches gloss over what went wrong, and Digibiashara walked the room through their critical incidents and what they learned. proof that African startups can ship world-class software on entirely open infrastructure.

RTOS in Linux without PREEMPT_RT: having your cake and eating it too

this talk took the room into embedded systems territory, specifically the tension between microcontrollers (deterministic timing, limited resources, C/C++ only) and single-board computers like the Raspberry Pi (rich Linux features, high-level languages, but best-effort scheduling). the speaker, a former Swiftlab engineer working on Ardupilot, described how the obvious path of using PREEMPT_RT (the real-time Linux kernel patch) creates significant overhead in building and maintaining custom kernel images across different Raspberry Pi models, which pulls focus away from the actual drone project.

the alternative he landed on came from studying Klipper, the 3D printer firmware, which separates concerns by letting a microcontroller handle low-level real-time operations (motors, sensors, time-critical timing) while a single-board computer runs high-level logic (path planning, user interface, G-code interpretation) and the two communicate over a structured serial protocol. translated to the drone world, that becomes a microcontroller handling IMU readings and motor control with a Raspberry Pi running mission logic over CAN Bus using DroneCAN and SocketCAN, which gives you standard network programming on the SBC side and message-based architecture that scales to multiple nodes.

the closing lesson was the right one: real innovation often means combining proven open-source patterns in new ways instead of building everything from scratch. the drone is still a work in progress, but the architecture is the takeaway.

are we making it easy for (new) contributors to grow?

speaker: Cornelius Emase (lochipi)

Cornelius closed out the conference with a talk that hit harder than its title suggested. he started by mapping how people actually find their way into open-source communities (friends, online searches, other communities) and then put the expectations against the reality. new contributors show up thinking "I'll contribute and grow fast, this will open opportunities," and then they hit the actual experience: slow replies, different community cultures, unclear pathways, and the silence that makes you wonder if you said something wrong.

his framing was empathetic on both sides. maintainers need to be patient, welcoming, and willing to point people to docs and direction. contributors need to be patient with themselves, stay curious, keep asking, and try things on their own before asking. community works when it feels human, which sounds obvious until you sit in a Discord channel for a week with no replies and start questioning whether you belong.

a great closer. the entire conference had been about building things in the open, and Cornelius reminded the room that the people building those things need to be supported as deliberately as the code itself.

day 2 done. seven talks, a wider range than day 1: low-level C++ infrastructure, security philosophy for beginners, embedded systems architecture, agency-scale open source, and community building. the throughline across both days was clear. Kenya's Ubuntu community is shipping production systems on open source, contributing back upstream, and thinking carefully about who gets to participate. looking forward to whatever comes next.