DEV Community: Bridget Amana

My Thoughts on Gemma 4

Bridget Amana — Sun, 24 May 2026 22:50:46 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Every AI tool you've ever used has had a landlord.

OpenAI decides what ChatGPT will and won't say. Anthropic decides what Claude will engage with. Google decides what Gemini will touch. You get a polished interface, a capable model, and somewhere in the basement, a terms of service document that is updated. You didn't argue with it. You accepted it because the alternative was not using the tool. You use the service, the service sets the rules, and you live inside those rules until they change or you leave.

What Gemma 4 does is different. Not better necessarily but different in a way that I think most of the coverage around it has managed to miss entirely.

When you download Gemma 4 and run it on your own machine, there is no landlord anymore. The model weights sit on your hardware. For the first time with a genuinely capable AI model, one that can reason, handle images, work through complex problems you are not a tenant. You own the thing. And ownership, it turns out, is a very different relationship than most people are prepared for.

What "open" has meant until now

The word "open" has been doing a lot of heavy lifting in AI for the past two years, and it has not always been honest work.

Meta's Llama models are called open, and in many ways they are, but the license has thresholds once you cross certain usage numbers, different rules apply, and you're back in a conversation with a legal department. Earlier versions of Google's own Gemma were released under a custom Google license that looked open but had enough commercial-use ambiguity that enterprise legal teams were flagging it as a blocker. Developers who wanted to build products on it were sometimes choosing other models not because Gemma was inferior for their use case, but because the licensing answer wasn't clean enough to ship with confidence.

Gemma 4 dropped on April 2, 2026 under Apache 2.0. If you've worked in software for any length of time, you know what that license means, it's the same license powering half the infrastructure the internet runs on. You can build a product on Gemma 4 and charge for it. You can fine-tune it on your own data and keep what you built. You can redistribute it. You can use it to compete with Google's own products. There are no usage thresholds, no revenue triggers, no conditions that quietly shift six months after you've built your entire pipeline around the model. The only things Apache 2.0 asks of you are that you keep the license text and preserve attribution notices. That is genuinely it.

The thing about the safety net you just let go of

When you use a cloud model through an API, you are living inside someone else's guardrails. There are things the model won't say, categories of output it's been trained and post-trained to avoid, layers of evaluation that exist between what you ask and what you receive. Some of those guardrails are genuinely annoying. Some of them are wrong, overly cautious. People have built entire communities around ways to get past them.

But those guardrails also mean that when something goes wrong, when the model produces something harmful or incorrect or dangerous the first line of accountability is the company, not you. They maintain the inference.

When Gemma 4 runs on your machine, that call comes to you. You decided to run it. You chose the deployment environment. You built the application on top of it. If you're the developer and something goes wrong downstream, the model provider is not upstream of you anymore. There is no upstream. You are the beginning and the end of the chain.

This doesn't mean local AI is irresponsible. Google's own Gemma 4 model card is explicit that it's been trained with safety considerations, that it has built-in safeguards, that it resists common adversarial prompts. Those things are real. But it also means something that Google's documentation says plainly and most breathless coverage of "AI you own" does not: safe deployment requires shared responsibility. The operative word being shared. You are now one of the parties sharing it.

The question it's asking isn't whether you trust Google. It's whether you trust yourself enough to not need them to.

Google Is No Longer Just a Search Engine

Bridget Amana — Sun, 24 May 2026 22:27:35 +0000

This is a submission for the Google I/O Writing Challenge

I want to talk about something that happened at Google I/O 2026 that I think most people are either misreading or not reading at all and that's the Search updates.

Before getting into what the Search updates actually are, I think the context matters, because the numbers Sundar dropped at the start of the keynote are the kind that should make you stop and recalibrate.

AI Overviews, that thing at the top of your search results that summarizes the answer before you even see any links now has 2.5 billion monthly active users. AI Mode, the more conversational, chatty version of Search that launched just a year ago, has already crossed 1 billion monthly users. And here's the part that caught me off guard: last quarter, total Search queries reached an all-time high.

I expected the opposite. The narrative I'd absorbed, especially from the people who hate AI Overviews, was that Google was cannibalizing its own product. That people were getting frustrated and leaving. But apparently the opposite is happening more people are searching more than ever.

Now, Google could be cherry-picking numbers. Companies do that. But 2.5 billion is hard to spin. That's roughly a third of the living humans on earth. Whatever you feel about AI Overviews personally, the thing has clearly become a normal part of how the world searches.

What actually changed in Search

The surface-level version is Google rebuilt the search box for the first time in over 25 years, made AI Mode more powerful, and added something called Information Agents.

The search box changes sound simple until you think about it. It now expands dynamically. You can throw images, files, videos, even an open Chrome tab at it. You're not writing a query anymore you're having a conversation with something that has context. The AI suggestions embedded in it aren't just autocomplete, they actually help you form a better question. Which is a subtle but weird thing when you think about it: Google is now shaping not just what you find, but how you ask.

The Information Agents part is where it gets genuinely new. You can now set a question, something like "tell me when flights from Lagos to London drop below a certain price" or "notify me when there's news about this company" and an agent runs in the background, monitoring the web around the clock, and surfaces an answer when something matches. You don't have to go back to Google. Google comes to you.

Taken separately, each of those things sounds like a nice upgrade. Taken together, they describe something that's no longer quite a search engine. It's closer to a research assistant you leave running.

The short-term effect

I think the honest thing to say first is that for the average person, someone who just wants an answer and doesn't much care about how it's packaged, the short-term experience of these Search updates is probably going to be pretty good. Better, even.

The new search box means you can dump a messier, more human question in there and actually get something useful back. Most people don't naturally speak in keywords. We speak in half-formed questions, context and all. "I'm trying to find a birthday gift for my friend who likes cooking" is a real question that a real person has. The old search box punished you for asking it that way. The new one is built for it.

The Information Agents thing, if it works, is solving a real annoyance. How many times have you searched for something, a flight, a product, an event only to have to keep going back every few days to check if anything changed?

So in the near term, I think a lot of the people who use Google casually are going to find it noticeably less friction-y. Searches that would have taken three tries now take one. Monitoring tasks that took repeated effort now happen while you're asleep. That's a real quality-of-life change, and I don't want to dismiss it.

The long-term effect

The reason AI Overviews upset so many people when they launched wasn't really about the answers being wrong, even though sometimes they were. It was about something more instinctive, the feeling that Google had inserted itself between you and the actual source. That you were being handed a summary written by a machine, when what you wanted was to find the person or place or article that actually knew the thing.

What Google announced at I/O 2026 takes that further. Information Agents that monitor the web and synthesize updates for you means that increasingly, your relationship with information on the internet is mediated by a Google model making decisions about what's relevant, what's changed, what's worth surfacing.

And the reshaped search box, with its AI-powered suggestions that help you "formulate your whole question" that's Google influencing what you even think to ask. Which is strange when you sit with it. Search used to be neutral in a way that's easy to take for granted. You had a question, you typed words, you got links, you decided what mattered. The human doing the reasoning was you. The shift that's happening, gradually, is that more of that reasoning is happening inside Google's systems before it ever reaches you.

The thing about the web underneath all of this

There's a question that's been circulating in tech circles since AI Overviews launched, and the I/O 2026 announcements make it more urgent. If Google's AI is reading the web and delivering synthesized answers, and enough people get their answers that way without clicking through to anything, then the traffic that sustains the people and organizations making that content slowly drains. Less traffic means less revenue. Less revenue means less content. Less content means less for Google's AI to learn from and synthesize.

News publishers have been bleeding traffic for over a year. Blogs, forums, independent writers. The places that make the internet worth searching are under pressure from the very thing that's supposed to make searching better.

Google built something excellent for consuming the web. And the better it gets at that, the harder it becomes to sustain the web it's consuming.

I don't have a clean answer to that. I'm not sure anyone does right now. But I don't think the answer is to slow down AI in Search. I think the answer is somewhere in how attribution, credit, and economic flow get redesigned for a world where most of the value transfer happens before anyone clicks. We haven't figured that out yet, and Google isn't going to figure it out alone.

To Summarize

The Search updates from I/O 2026 are good for users in the short term in ways that are pretty easy to see. They're complicated for the web in the long term in ways that are harder to trace. And they represent a shift in what Search actually is, which is from a tool that helps you find things to something closer to a layer that mediates your relationship with information itself.

AI is slowly destroying open source and its not even done yet

Bridget Amana — Tue, 19 May 2026 14:22:33 +0000

With the wide adoption of AI, we have seen the positive and negative impact it has had on businesses across the board. Open source was supposed to be one of the biggest beneficiaries. The idea was that it would lower the barrier to contributing, help developers move faster, catch bugs earlier, make maintaining projects less of a grind.

What the ecosystem is actually facing looks nothing like the vision. The problems AI has introduced into open source are not small or temporary growing pains. They are hitting maintainers, contributors, projects, and the funding models that kept everything running. And it keeps getting worse.

Exhibit A: Vibecoded slop is the new foundation

One of the core benefits of open source is that you do not have to reinvent the wheel. If you need to convert units or handle dates, you pull a well-maintained package and move on. You trust the foundation so you can build something better on top of it. Except now, the foundation is being replaced by "vibecoded slop."

We’re seeing a flood of AI-generated projects hitting registries with zero oversight. It gets pushed out, it looks fine on the surface, and people install it. This vibecoded slop is now the foundation others are building on. And when the foundation is bad, everything on top of it inherits that. We have seen a wave of application leaks and breaches lately and a significant number of them trace back to projects that were never properly looked at before people trusted them with real data. It is a chain of vulnerabilities waiting to be pulled.

Exhibit B: AI agents are drowning the people keeping open source alive

Open source maintainers have always had to deal with bad pull requests. That isn't new. What is new is the volume.

AI agents are now being set up specifically to scan repositories, find open issues, generate code, and fire off pull requests automatically. They ignore the project's contribution guidelines and code style completely. The guidelines are there for a reason, they make maintenance manageable and keep the codebase consistent, but the agents do not care about any of that.

Shadcn said it plainly in a tweet on March 8: "Mass-generating PRs with your agents and clawbots isn't helping open source. It's quietly burning out the people who actually maintain it. Please stop."

The maintainers on the receiving end of all this are mostly volunteers. They are not paid. They do it because they care. And now instead of spending that energy on work that actually moves the project forward, they are stuck triaging noise. GitHub acknowledged how bad it had gotten and in February 2026 introduced two new repository settings so maintainers can disable pull requests entirely or restrict them to collaborators only. That a platform the size of GitHub had to build a feature just so maintainers could protect themselves from contributors says everything about where we are.

Exhibit C: Why would anyone bother anymore

Open source was built on a simple but powerful idea. You run into a problem, you work through it, and instead of keeping that solution to yourself you put it out there so the next person does not have to go through the same struggle. That act of sharing is the whole spirit of it. That is what built the ecosystem.

Stormy Peters, AWS Head of Open Source Strategy, put it in a way that probably resonates with a lot of developers right now "I generated it in three seconds. You could generate it in three seconds if you needed it. Why would I spend my time pushing it upstream when anyone could just generate it on demand?"

That question does not have an easy answer anymore. If any solution can be generated on demand, the motivation to package it, document it, maintain it, and share it starts to feel pointless. The whole value of putting something upstream was that it saved the next person the trouble. But if there is no trouble to save them from, why bother?

Conclusion

AI is not just introducing bugs or burning out maintainers, though it is doing all of that. It is making that choice feel irrational. Why share what anyone can generate? Why maintain what nobody values enough to contribute to properly? Why keep volunteering your time to triage noise?

Those questions do not have good answers right now. And the people who built the things you depend on are the ones sitting with them. Most will not make an announcement when they decide it is no longer worth it. They will just quietly stop.

Open source survived a lot of things. I am very sure it will survive with a lot of help from the community of course.

What Google Cloud NEXT '26 Taught Us About Agent Governance

Bridget Amana — Thu, 30 Apr 2026 00:28:11 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

About halfway through the Developer Keynote, Emma Twersky tried to get the Planner Agent to increase the race budget so every runner could get glow sticks and LED sunglasses.

And to everyone’s surprise, it worked.

The next speaker was invited on stage to explain how to prevent exactly that from happening.

I couldn’t move on from that because what just happened was one of the most honest and quietly alarming demonstrations I've seen at a tech conference in years. An agent with write access to a financial database was talked into making an unauthorized budget change through normal conversation.

Not through a hack or an injection attack. Just a user asking nicely.
And most of the discussion I've seen coming out of NEXT '26 is about Gemini 3.1 Pro, the new TPUs, and whether "vibe clouding" is going to stick as a term. We should be talking about something more consequential: what happens when your agents can discover each other, delegate to each other, and act on your behalf and who controls that?

What she demonstrated, before Ankur Kotwal came on stage to fix it, was a real attack surface. The Planner Agent had access to a Finance MCP server with both read and write tools. Emma asked it, through normal conversation, to increase the budget. The agent complied because nothing told it not to. There was no policy. There was no boundary. There was just a capable agent, a persuasive user, and a write-enabled tool sitting there waiting.

Ankur's fix was genuinely clean. He navigated to Agent Gateway, selected the Planner agent, located the Finance MCP server in its allowed tools, added a condition named read-only-finance, set ReadOnly to True, and saved. The same prompt now fails gracefully.
The mechanism underneath Agent Identity is more interesting than the UI makes it look. Unlike service accounts, which function like a master keycard shared across an entire system, each deployed agent gets a unique cryptographic identity. Policies attach to that identity. The gateway enforces them on every call. It's zero-trust, properly applied to a new kind of principal: not a user, not a service, but an agent.

This is the architecture the industry needs. The uncomfortable part is that we needed it because agents behave like eager-to-please interns who will do whatever they're asked unless someone explicitly wrote down that they shouldn't. They don't have judgment. They don't have intent. They have instructions and tools, and if the instructions don't say "don't touch the budget," the tools will touch the budget. Organizations are deploying agents into production faster than they're defining what those agents are and aren't allowed to do and most of the time, nobody finds out until something goes wrong. An overprivileged agent doesn't need to be hacked. It just needs to be prompted.

Richard Seroter framed this as a reason to "shift down, not left" on security. The industry has spent a decade telling developers to own security earlier in the pipeline — shift left, catch it in the IDE, integrate it into CI/CD. Seroter's argument was that this model breaks under agentic workloads. You can't ask every developer building agents to be a security expert. The platform needs to absorb that responsibility. Agent Gateway, Agent Identity, and Model Armor are Google's answer to where that responsibility lives.

It's a compelling argument. It's also, notably, an argument for why you should run your agents on Google Cloud.

What I really loved is that they showed the exploit first. Then they showed the fix. They didn't start with the policy screen and say "imagine if this didn't exist." They let Emma actually do the bad thing, let the audience have a moment of "wait, that worked?", and then brought in the answer.

Most conference security demos work the other way, they show you the protection and imply the threat. Google showed you the threat and then showed you the protection, which means you actually understand what you're protecting against.

Agency Is the New Risk

Bridget Amana — Sat, 25 Apr 2026 22:58:46 +0000

This is a submission for the OpenClaw Writing Challenge

For years, the AI safety conversation lived in a specific place. The worry was the answer on the screen: hallucinations, bias, misinformation, bad output from a model you had asked a question. The implied solution was always some version of human oversight. You read what it said, you decided what to do with it, and the worst case was usually that you acted on something that turned out to be wrong.

OpenClaw moved that conversation somewhere harder. Not by being smarter than other AI, but by being the first AI tool to reach consumer scale while making agency the default.

When your assistant can read your email, book a flight, run shell commands, and send messages on your behalf, the question is no longer whether the AI said something wrong. It is whether the AI did something wrong. And those are not the same problem at all. One is a content moderation issue, the other is an authorization problem, an access control problem, a governance problem.

OpenClaw did not create this problem. It just made it impossible for anyone to pretend it was still theoretical.

What changed

A chatbot that produces a wrong answer sits behind glass. You read it, interpret it, and act on it or not. The error is yours to catch. An agent that acts for you removes that buffer. It does not wait for your interpretation. It decides what your instruction means, picks a course of action, and executes. The gap between what you intended and what the agent understood becomes consequential in a way it never was when AI was only generating text.
James Nguyen, writing for TNGlobal in April 2026, framed the shift precisely: "The concern is no longer what models produce. It is authority: who is acting, under whose permissions, inside which trust boundary, with what safeguards."
OpenClaw makes this concrete. It connects to your email, your files, your calendar, your messaging apps. Every thirty minutes, a heartbeat process wakes the agent, checks a list of things it has been asked to monitor, and decides whether to act without prompting from you. Every permission you grant the agent is also a permission that anyone who compromises the agent now has. That is not a flaw in OpenClaw specifically. It is the nature of delegated authority.

What happened when it spread

The security picture that emerged after OpenClaw went viral in January 2026 was not a single incident. It was an entire category of problems arriving at once, and it is worth going through them, because each one points at a different dimension of the same underlying challenge.

The most technically acute was CVE-2026-25253, rated 8.8 out of 10 on the CVSS severity scale. A vulnerability in the gateway's WebSocket handling meant that a single unvalidated URL parameter could trigger a one-click remote code execution chain. Critically, binding the gateway to localhost was not enough protection. The exploit pivoted through the victim's browser, meaning you did not need to be internet-facing to be compromised. Censys tracked publicly exposed instances growing from roughly 1,000 to over 21,000 in a single week. An independent researcher found over 42,000 exposed instances, of which 93% showed authentication bypass conditions.

At the same time, ClawHub, the public skill registry, became a distribution channel for malware. By mid-February 2026, 341 confirmed malicious skills had been discovered in the registry, roughly 12% of it. Some delivered Atomic macOS Stealer. One posed as a cryptocurrency trading tool and harvested wallet credentials silently. Later scans put the number above 800, closer to 20% of the registry. Cisco's AI security research team documented a skill performing silent data exfiltration without the user's awareness and noted the core issue: the registry lacked adequate vetting to prevent malicious submissions.

The harder version of the vetting problem is structural. Reviewing an AI skill is not like reviewing a software package. It requires understanding what the skill will instruct the LLM to do, not just what code it contains. There is no automated scanner that does that reliably yet.
Then there was prompt injection, which is the attack class that most people outside security had not heard of before OpenClaw made it legible to a general audience, and it deserves the most attention because it is the one that does not get patched out.

Contabo's security guide documents one real incident: someone embedded malicious instructions in an email signature. When the OpenClaw agent processed that email to generate a summary, it followed the hidden instructions instead of the user's. PromptArmor demonstrated separately that link preview features in Telegram and Discord could be turned into data exfiltration pathways, causing the agent to transmit confidential data to an attacker's domain automatically, without the user clicking anything.
What makes this different from a conventional bug is architectural. As Penligent's security research puts it: "In LLM-driven agents, instructions and data occupy the same token stream. There is no firewall between data the agent reads and instructions the agent follows." When a chatbot gets prompt-injected, the worst outcome is bad text. When an agent gets prompt-injected, the worst outcome is shell execution, file modification, and outbound messages sent through real accounts. The blast radius is the difference between a chatbot and an agent, which is exactly the distinction that makes agentic AI compelling in the first place.

The standard response to software security problems is to patch the bugs, improve the defaults, and educate the users. OpenClaw has done all three. CVE-2026-25253 was patched within days. ClawHub added VirusTotal scanning. The community has produced a serious body of hardening guidance in a short time. But prompt injection is not a bug. It is a consequence of how language models process text, and there is no patch for it. You can reduce the blast radius. You cannot eliminate the attack surface.

The governance gap

China's response to OpenClaw is usually framed as Beijing being restrictive about foreign technology. That framing misses what is actually interesting about it.

In March 2026, Chinese authorities issued notices to state-run enterprises and the country's largest banks warning against installing OpenClaw on office devices. Some employees were banned from installing it on personal phones connected to company networks. The restrictions extended to families of military personnel. China's National Vulnerability Database published security guidelines. The People's Bank of China issued a separate warning for the financial sector.

At the same time, local governments in Shenzhen and Wuxi were offering multimillion-yuan subsidies to companies building on the same platform. Tencent, Alibaba, Baidu, and MiniMax had all shipped OpenClaw-based products. MiniMax shares rose 640% in two months.
Kendra Schaefer, partner at Trivium China, told Bloomberg: "Chinese regulators typically respond with extraordinary speed to threats from emerging technologies, but the rate of adoption of OpenClaw and other agentic tools is still outpacing them."

China, which has some of the most developed state capacity for technology regulation anywhere in the world, could not form a coherent position fast enough. The national government was restricting it while local governments were subsidizing it, simultaneously. The rest of the world is in the same position, just without the bans.
There is no established liability standard for when an agent acts outside a user's intent. There is no certification requirement before an AI system holds OAuth tokens for your inbox. There is no equivalent of PCI-DSS for agents handling personal data. NIST has an AI Agent Standards Initiative in early stages. OWASP has classified prompt injection as LLM01. The UK's NCSC has framed it as a "confused deputy" problem. None of this is implemented anywhere at the scale OpenClaw is already operating.

The question that matters

There is a version of this story where OpenClaw matures, the security ecosystem catches up, and it becomes what it was always meant to be: a genuinely useful assistant that handles the tedious parts of digital life. That is plausible.
But something has already happened that will not un-happen. Millions of people installed an AI agent with broad system access, most without understanding the threat model, and the world got a clear view of what happens when agentic AI spreads before the governance does.

The window we have now, where agentic AI is still mostly used by technically adventurous people who understand at least part of the risk, will not stay open. The tools are getting easier to install. The demos are getting more compelling.

OpenClaw did not create the agentic AI era. It just arrived early enough that we could watch, in real time, what it looks like when capability outpaces the systems meant to govern it.

The Challenges Threatening Open Source

Bridget Amana — Wed, 25 Feb 2026 20:33:12 +0000

Open source software (OSS) serves as the digital backbone of modern society, providing the foundation for the applications and services we rely on daily. However, the same openness that drives innovation also introduces significant risks. As our dependence on shared code grows, the obstacles facing the ecosystem become more complex. Understanding these challenges is the first step toward building a more resilient future for software.

Security vulnerabilities

Many open source initiatives are maintained by small groups of volunteers or even a single individual. While this grassroots approach is a testament to the community's spirit, it creates a "single point of failure." Inactive or abandoned repositories can harbor known vulnerabilities that remain unpatched for years, leaving any system that uses them exposed.

It gets messier when you factor in dependency chains. Most open source software relies on other open source software, and those chains can get long and hard to track. One weak link in that chain and suddenly you've got a security problem that ripples outward. The transparency that makes open source so powerful is also what makes it vulnerable here. Attackers can see the same code that the community uses to fix things, and sometimes they get there first. That's why regular auditing and automated scanning have become so critical, not just a nice-to-have.

Sustainability

Every open source project has people behind it, and keeping those people around is one of the trickiest parts of the whole thing. These projects need funding, they need resources, and most of all they need contributors who stick around. When a project becomes essential to global industry but lacks a support structure, the burden often falls on a few individuals.

This leads to maintainer burnout—a state where the pressure of fixing bugs and managing requests outweighs the joy of contributing. Sustainability is not just a financial issue; it is about creating a culture where contributors feel supported. If the software that millions of companies depend on is treated as a "free" resource without reinvestment, the very people who build it may eventually stop showing up.

Maintaining code quality

Open source invites anyone to contribute, and that's one of its greatest strengths. You get people with all kinds of backgrounds, skill levels, and ideas jumping in, and that kind of diversity makes projects genuinely better. But it also makes keeping the code tight and consistent a real challenge.

When contributions are coming in from all over the place, without solid review processes or clear guidelines, things can start to slip. Small issues add up, and before long you've got a codebase that's harder to maintain and trust. It's one of those problems that doesn't announce itself loudly. It just quietly builds up until someone notices something is off.

Looking ahead

Open source has never been just about code. It's about curiosity, generosity, and the belief that collaboration makes better things and better people. The next few years will test that belief like never before. But if we do what we've always done best, show up, share the work, and care for each other, we won't just sustain open source. We'll sustain the spirit that started it and ensure the success we've built continues for the good of the modern world.

Getting Your First Open Source Contributors

Bridget Amana — Mon, 16 Feb 2026 10:49:12 +0000

I have built a number of open source projects, including snippet shot, tailwindcss migrator, and pixlated. After building, I shared it on forums and communities, made it clear in the readme that 'contributions are welcome,' but still got zero contributions. It made me wonder what exactly I was doing wrong. I looked at these repos from outsider's perspective. I noticed that, aside from the big “contributors are welcome” message, nothing else was inviting me to contribute. From there, I discovered a few more issues as to why my project wasn’t receiving contributors.

Show how to use and setup your project

When I first shared the repo, there was nothing guiding users on how to set up the project. I had a README but it was missing installation instructions. Without this, potential contributors face unnecessary friction. If you can't get a project running, how can you contribute to it? Good installation instructions aren't just 'npm install.' They should walk through the complete setup: prerequisites, installation steps, how to run locally, and what success looks like.

Keep your project active

I have scrolled past repos countless times simply because the last activity was months ago. It subtly signals that this project isn’t active so why waste my time contributing. When I looked at my projects from that perspective, I realized I wouldn't even contribute to them if they weren't mine. You don't need daily commits, but aim for visible activity at least once a month. This could be merging a PR, updating a dependency, adding an example to your docs, or even just triaging issues. The goal isn't busywork, it's showing the project has a pulse. On Pixlated, I set a reminder to review and update something small monthly, even during quiet periods. That consistent timestamp matters more than you'd think.

Open up a few issues first.

Sometimes, people don't know how they can contribute. Be their guide. Opening a few issues paves the way for more contributors. I looked at the project and it seemed dry—maybe people didn't know where to start. Contributions on pPxlated started coming in when I opened up a few good first issues. The first issue I opened was to 'convert all project images to .webp format'. This was after running the site on page speed insights and it pointed out that performance issue. I could have done this instantly by myself but I thought, this is a good simple first issue for someone just getting started with open source contributions. Within a couple of hours, someone commented asking to be assigned. After that, I used the same strategy. I opened simple issues that wouldn't take more than 5 minutes to do. With this constant interaction, other people started opening issues. A few issues were ignored till they were further broken down in the issue description.

It shows that people want to contribute but are confused about what they can do.

Show appreciation to your previous contributors.

Contributors aren't paid for their work, so recognition matters. Seeing your GitHub profile on a project gives contributors that dopamine hit that makes them want to return. Give people reasons to be excited: thank contributors after a successful merge or add a contributors section to your README. This appreciates past contributors and signals to new ones that their efforts will be valued.

Publicize your work

You can't contribute to what you don't know about. Contributions aren't coming in because your project is still very much hidden. Share your project on communities and social media. Announce what you're building, that it's open for contributions, and when you open new issues. I posted on Reddit and created an article on Dev.to to share the project. Neither got much traction. What actually kickstarted contributions was a Twitter post announcing good first issues. Don't constrain yourself to one platform. Twitter worked for me because I was already consistent and had followers there. It might not work for you if you're just starting out. So, go where your audience is. I didn't just stop at one post but continued giving updates regularly.

Get your project up and running first

People won't contribute to what isn't working. Project owners might think building together is part of the open source spirit, but contributors want to improve something functional, not debug a broken foundation. Get the project started on your own and show that crucial features are working. Don't build halfway with nothing visibly working and expect people to join. This doesn't mean your project needs to be feature-complete, but there should be a working core that people can clone, run, and see in action. For Pixlated, I made sure the basic image pixelation worked and the site was deployed before asking for contributions. Contributors could visit the live site, understand what it does, then look at the code to improve it. Starting with a half-built project where nothing runs yet means contributors spend their time figuring out your vision instead of improving it.

Conclusion

If your project hasn't had contributions, the first step is to audit your readme. Make sure someone can understand what it does and how to run it within 30 seconds. Then work on sharing your project to get eyes on it. The more eyes you get on it, the greater your chances of getting a contributor. The contributors are out there, you just need to make it easy for them to find and join you

Exploring The Career Of A Technical Writer

Bridget Amana — Mon, 16 Feb 2026 10:45:29 +0000

Who a Technical writer is

A technical writer (sometimes called a tech writer) is someone who takes complicated technical concepts and makes it easy for people to understand. They translate jargons to easy-to-understand documentation. While many people think technical writers just write "guides", their role is more expansive than that:

Information Design: They determine how to structure information so users can find what they need quickly.
User Advocacy: They represent the end-user, often testing products to identify points of confusion before the documentation is even written.
User Advocacy: They speak up for you, the end-user. They'll test products and spot confusing parts before the documentation is even written.
Content Creation: They create all sorts of materials, including:
- API Documentation: Instructions that help developers use software tools.
- Help Systems: Those searchable knowledge bases you use when you're stuck.
- Standard Operating Procedures (SOPs): Internal guides that show employees how to do their jobs.
- White Papers: Deep-dive reports that explain specific technologies or solutions.

Skills Needed to Be a Technical Writer

Technical Proficiency

You don't need to be a programmer, but you'll need some basic technical knowledge. If you're documenting a Python tool, for example, understanding basic Python concepts helps you ask better questions and catch mistakes.

Research

Research is at the core of what a technical writer do. Writers dig into unfamiliar topics, interview subject matter experts, and test products themselves to truly understand what they're explaining. Good research means you can explain something clearly even if you weren't the one who built it.

Communication and Collaboration

Technical writers work with developers, product managers, designers, and customer support teams. You need to ask the right questions and build good relationships with stakeholders.

Writing and Editing

This might seem obvious, but it's about more than just grammar. You need to write clearly, cut unnecessary jargon, and know when to use a diagram instead of a paragraph. You're always thinking: "What's the simplest way to say this?"

Role of A Technical Writer

Create Documentation
Translate Technical Information
Research & Understand Products
Organize Information
Maintain and Update Content

Your guide to getting started

If you're interested in becoming a technical writer, here's the good news: you don't need a specific degree. Many technical writers come from writing backgrounds, while others transition from technical roles like software development or IT support. The key is being curious, willing to learn, and able to explain things clearly.

Improve Site Performance by Auditing Unused Code

Bridget Amana — Mon, 08 Dec 2025 16:47:52 +0000

Overview

Shipping unused CSS and JavaScript does more than clutter your codebase. It directly affects your site's performance. Every unused rule or function is extra data the browser has to download and parse before the page becomes interactive. While you could manually compare your styles against your HTML, modern browsers provide a more easier solution: the Coverage tool.

What the Coverage tool does

The Coverage panel in developer tools analyzes every CSS and JavaScript resource loaded on a page. It calculates which parts of each file are actually used during rendering and highlights the unused sections. This gives you a clear view of what can be safely removed.

How it works

Open DevTools (Cmd+Option+I on Mac or Ctrl+Shift+I on Windows).
Open the Command Menu (Cmd+Shift+P or Ctrl+Shift+P).
Type Coverage and select Show Coverage.
In the Coverage tab, click the reload icon to start recording.

The panel lists all CSS and JavaScript files, along with the percentage of code executed. Red highlights indicate unused sections. You can also filter the results to show all resources or only CSS or only JavaScript.

Analyzing Results

Once the page reloads, the Coverage tab displays the used and unused portions of each file. These results are helpful but require proper interpretation.

Pseudo classes such as hover or active appear unused when they are not triggered.
Media query rules appear unused if your current viewport does not match the query.
Interaction based styles and animations will not register unless activated during recording.
JavaScript that runs only after specific actions will appear unused until those actions occur.

Conclusion

Performance improvements do not always require complex changes. Identifying and removing unused CSS and JavaScript is a simple and effective way to reduce page weight. The Coverage tool helps you find what is no longer used on the page, and removing that results in a faster site.

Understanding why 100vh behaves differently on mobile

Bridget Amana — Mon, 08 Dec 2025 16:38:09 +0000

The expected behavior of 100vh is simple. When you apply it to an element, it should take up the full visible height of the screen so no scrolling is required. This works perfectly on desktop. On mobile browsers, especially Chrome and Safari, the behavior is different. The bottom part of the page sits behind the browser interface, so the content appears cut off unless you scroll. This article focuses on understanding why this happens and how to fix it.

The problem

100vh has always been the quick way to create a full height layout. The issue is that mobile browsers do not calculate 100vh using the actual visible space. The browser address bar and tab bar are not included in that calculation. When those bars expand or collapse, the visual viewport changes, but 100vh does not adjust.

Here is a simple example.

<div class="app-shell">
  <header>
    <h1>My App</h1>
  </header>
  <main>
    <p>This is the main content area.</p>
  </main>
  <footer>
    <p>Footer content here.</p>
  </footer>
</div>

.app-shell {   
  display: flex;     
  flex-direction: column;     
  min-height: 100vh; 
}  

main {     
  flex: 1; 
}

On mobile, part of the layout will sit behind the browser bar. When you scroll, the bar collapses and the layout suddenly fits. This is the inconsistency developers run into.

Many older articles suggest using webkit-fill-available. This used to work in certain contexts but is unreliable today and does not solve the root issue.

100dvh as the fix

A more accurate way to handle full height layouts on mobile is to use the new dynamic viewport unit: dvh.

Dvh stands for dynamic viewport height. It is one of three new viewport units (svh, lvh, dvh). The dynamic version adjusts based on the current visible viewport. If the browser address bar collapses or expands, dvh updates in real time.

Using our earlier example, the fix looks like this:

.app-shell {     
  display: flex;     
  flex-direction: column;     
  min-height: 100vh;     
  min-height: 100dvh; 
}

Setting the height to 100dvh tells the browser to size the element using the actual visible viewport height. This prevents the layout from slipping behind the browser UI on mobile.

Conclusion

Dvh provides a practical and reliable fix for the long standing 100vh issue on mobile browsers. It responds to changes in the viewport and keeps your layout visible without relying on outdated workarounds. While browser behavior may continue to evolve, dvh is currently the most accurate way to create full height layouts on mobile.

A Practical Guide to Color Contrast for Web Developers

Bridget Amana — Mon, 08 Dec 2025 12:09:58 +0000

Color contrast determines the readability of your interface in real-world conditions, affecting everything from quick button taps to long-form reading. You notice this impact most when you are outside with low screen brightness or using a device with a weaker display.

This is why contrast is not just a design concern; it is a core part of front-end engineering. You already invest time in performance, layout, and stable interactions. Contrast belongs in that same category because it dictates how reliably your UI performs across different environments.

What Contrast Actually Measures

The Web Content Accessibility Guidelines (WCAG) use a formula comparing the relative luminance of two colors to determine visibility. While you do not need to calculate this manually, you must know the targets.

Normal text requires a ratio of at least 4.5:1.
Large text requires a ratio of at least 3:1.

These values sit on a scale from 1 to 21, where higher numbers represent stronger contrast. Black text on a white background is 21:1, while white on white is 1:1. Most readable color pairs in modern web projects land between 5 and 14.

These ratios are not arbitrary numbers chosen at random. They are based on how people with different visual acuities perceive brightness. Even users with typical vision lose clarity in low light or outdoor glare, so a pair that passes at 4.5:1 will survive more environmental factors than a pair hovering at 3:1. This is why aiming for the bare minimum works for headlines but often causes readability issues for smaller body text.

Checking Contrast While You Work

For immediate feedback, your browser is the fastest tool. By opening DevTools and inspecting a text element, you can view the contrast ratio directly within the accessibility or styles panel. This allows you to catch accessibility bugs early in the process, particularly when you are blocking out layouts or experimenting with new theme colors.

However, browser DevTools are most accurate for text on flat, solid backgrounds. If your text sits on top of a gradient or a complex image, the browser cannot always calculate the background color reliably, so you will need a dedicated tool.

Using Dedicated Contrast Checkers

Small color swatches can be misleading because some combinations technically meet the math requirements but still look weak in a real interface. Tools like colourcontrast.cc are valuable here because they update the entire page preview based on your selection.

This approach lets you see titles, paragraphs, and UI components using the color pair at different scales. It gives you a realistic sense of stability that a simple calculator cannot provide. Sometimes a ratio of 4.7:1 looks fine in isolation but feels too thin once placed inside a dense layout, and seeing it in context helps you make the right judgment call.

Automating the Workflow

To reduce guesswork across your team, you should integrate automated checks. While linting plugins like eslint-plugin-jsx-a11y help catch missing labels, they sometimes struggle to calculate color contrast since they cannot always see your CSS files.

People often treat accessibility as a separate compliance requirement, but in practice, contrast improves basic usability for everyone. It makes text easier to scan, reduces eye strain, and keeps interfaces clear on older hardware. By treating contrast as a technical constraint rather than just an aesthetic choice, you help make the web a better place.

Finding Open Source Projects to Contribute To

Bridget Amana — Mon, 08 Dec 2025 11:46:02 +0000

Finding open source projects to contribute to is usually harder than people make it sound. Most articles give the same standard advice which tells you to search for “good first issues” and filter by labels. In reality, this does not always work because maintainers often forget to label issues. Many of the “good first issues” you find belong to old or inactive projects, so you end up wasting time trying to contribute to something no one maintains anymore.

From my experience, there are much more effective ways to find active work.

Follow Active Contributors

A better approach is to follow active open source people rather than just staring at repositories. When you follow contributors and maintainers you trust, your GitHub feed becomes a powerful tool. You start seeing the pull requests they open, the issues they interact with, and the new projects they star.

This gives you visibility into living projects instead of abandoned ones. It is much easier to join projects this way because you are walking into a space that already has activity around it.

Contribute by Testing, Not Just Coding

Most people overlook the fact that contributing is not limited to opening pull requests. For my first year in open source, I mostly contributed by testing projects. I would run the project locally, use the features, and actively look for problems.

These problems could be anything from an accessibility issue or a broken UI on mobile screens to small performance lags or grammar errors in the documentation. All of these details matter. When you find them, open an issue. You can take on a few of them yourself or leave them for other beginners to tackle. This helps maintainers more than you think, and it gets you familiar with the codebase at the same time.

Use Curated Discovery Channels

Another reliable way to find active projects is through trusted Twitter accounts that share open source opportunities. These are the verified accounts I follow:

-GitHub Projects
-Open Source Projects
-Meta Open Source
-Tom Doerr

They post a wide range of projects with different tech stacks, so you can choose something that matches your current skill level or interests.

Don't Ignore Small Projects

I always tell beginners not to ignore small projects. Many people only want to contribute to popular repositories with thousands of stars, but those projects started small too.

Smaller projects are usually more open to beginners and have maintainers who respond faster. You often learn the most in places where you are not competing with hundreds of other contributors. Start small to build your experience, and then move into larger communities when you feel ready.

Finding projects is not always straightforward, but there are better ways than relying on labels. Follow active contributors, test real projects, open issues, and do not overlook the smaller repos. This approach keeps you in the flow of active work and leads to more meaningful contributions.