Open Source as a Career Strategy: Lessons from Dhiya

The Internal Tool That Became Public

Dhiya NPM started as an internal library. We'd built client-side RAG for the Sunbots Management System's document analysis features and for SmartON's document search capability. The code was working, it was useful, and it solved a problem I hadn't seen a clean solution to: running a full RAG pipeline entirely in the browser without a server.

The decision to publish it as open source wasn't primarily a career strategy — it was partly an experiment, partly a desire to see whether others found the approach useful. What happened after publication taught me more about career-building than I expected.

What Open Source Actually Does for Your Career

It makes your thinking legible. A conversation where I describe Dhiya's architecture to a potential client or collaborator is much less informative than pointing them to the code and documentation. Real code reveals how you think about trade-offs, what you care about in system design, and where the limits of your understanding are. No resume section does this.

It attracts the right conversations. The people who reach out because they've read Dhiya's code or used it in a project are self-selected: they're technically engaged, curious about the same problems, and ready for a substantive conversation. The quality of inbound interest from open source work is qualitatively different from inbound from a LinkedIn profile.

It compounds over time. A blog post about client-side RAG has a lifespan measured in weeks. A published package has a lifespan measured in years. Every new user, every GitHub issue, every usage question compounds the visibility. The work keeps working after I've moved on to other projects.

It creates accountability. When code is private, "good enough" is a function of internal standards. When code is public, "good enough" is a function of what others will see, use, and critique. This accountability produces better work. The Dhiya NPM code is cleaner, better documented, and more carefully considered than equivalent internal code I've written.

The Practical Considerations

Choose problems that are genuinely useful to others. Dhiya NPM solves a real problem (client-side RAG) that others encounter. An open-sourced internal utility that solves a problem specific to your exact stack and configuration won't attract meaningful engagement. The question before publishing: would I have found this useful if someone else had built it first?

Documentation is the product. Code without documentation is an obstacle, not a contribution. The most used open-source projects are well-documented to the point where someone unfamiliar with the codebase can answer most of their own questions without reading the source. Getting documentation to that level is slow and often unrewarding work — and it's what separates packages that get used from packages that get starred and abandoned.

Be responsive to early issues. The first 10–20 GitHub issues on a new package set the community tone. If you respond quickly and thoughtfully to early issues, you attract more issue reporters who assume responsiveness. If you let issues age, you attract fewer reporters and more frustrated users who quietly stop using the package.

What I'd Do Differently

Publish earlier. Dhiya NPM was internal for 8 months before I published it. During those 8 months, I was refining it for our internal use cases. That refinement was useful, but it wasn't necessary for a useful v1 — a v1 that solved the core problem with rough edges would have attracted feedback that accelerated the refinement better than internal-only iteration.

The cost of publishing a rough v1 is some embarrassment. The cost of not publishing is 8 months of foregone feedback. The math is clear in retrospect.