DEV Community: Dmitry Titov

Help Improve Open Source Onboarding: 3-Minute Survey for Contributors

Dmitry Titov — Fri, 06 Jun 2025 17:44:45 +0000

🚀 Open source drives the modern web, but getting started can feel overwhelming — especially for newcomers.

As part of an ongoing research project and upcoming publication, I'm running a short survey to understand how developers first entered the open source world, what challenges they faced, and what helped them stay.

👉 Take the 3-minute anonymous survey here

Google Forms

🎯 Who is this for?

This survey is for anyone who has ever tried contributing to open source — whether you’re a regular contributor, a beginner, or someone who attempted it once.

I'm currently conducting research for a publication that explores how structured mentorship can help improve onboarding and retention in open source communities. Your input will help:
• Identify common barriers for newcomers;
• Understand how mentorship impacts long-term engagement;
• Inform a proposed model called Open Source Practicum aimed at building inclusive, educational OSS environments.

The results will be summarized in a public post, and may be used to inform future academic or community research efforts.

⸻

📣 Spread the word

If you've been part of OSS in any way — or tried to be — I’d love your input.

And if you know someone who might have something to say, feel free to share 💙

Thanks in advance!

— Dmitrii Titov

Open Source Is Waiting for You: How to Stop Being Afraid and Start Contributing

Dmitry Titov — Mon, 02 Jun 2025 00:20:41 +0000

🧵 The Shortage of Open Source Contributors: Myth or Reality?

Unfortunately — it’s reality 😔

Do you know how many developers there are in the world today?

📊 According to Evans Data Corporation, in 2024 there are over 28.7 million developers globally.

Sounds like everything should be built already, right?
But let’s look at how many actually contribute to open source…

📉 Linux Foundation Report (2024)

Based on this survey of 332 developers involved in OSS:

👥 Out of 332 people:

💥 Even among this engaged group, only 17% are consistently active contributors*.
*Sum of maintainers (10%), core contributors (5%), and committers (2%).

That’s just 1 out of 6 people, and this is from a motivated audience!

🧵 Of course, these numbers don’t capture everyone who helps open source thrive.

People contribute by writing docs, triaging issues, translating content, answering questions, giving feedback — and it all matters.

Without these roles, maintainers would burn out even faster 💀.

💬 JetBrains Survey Confirms It

In JetBrains’ Dev Ecosystem 2023 (20,000+ devs):

✅ Regular + full-time contributors = just 5–6%

🎯 Core of active OSS devs = ~15% at best

🧮 Let’s Do the Math

If we take the optimistic 17% of 28.7M developers:
🔧 ≈ 4.9 million active contributors

But more realistically (5–11%):
🧑‍💻 ≈ 1.4–3.1 million — the entire OSS backbone

Let that sink in — that’s fewer people than in some cities.

🇺🇸 What About the US?
According to GitHub Octoverse 2024:

🌍 India, China, and Brazil are growing rapidly.
🇮🇳 India is set to become the #1 contributor country by 2028.
🇺🇸 The US still leads, but its share is gradually declining.

🚧 Open Source Is Built By a Minority

Even in ideal conditions:

⚠️ ~80% of developers don’t contribute consistently.

But instead of panic, this should be a call to action 🧭

🧩 Ways to Contribute Beyond Code

📘 Docs
🐞 Bug reports
🌍 Translations
💬 Discussions
🧑‍🏫 Tutorials
🧠 Feedback
🔍 Testing
🤝 Community support

💡 Why Don’t More Devs Contribute?

Here are the most common blockers:
• 😰 Fear of judgment (“What if my PR gets mocked?”)
• 🤷 Low confidence (“I’m not experienced enough…”)
• ❓ No idea where to start
• 🌐 Language barrier
• ⏳ No time (work, burnout, life…)

These aren’t character flaws. These are fixable with guidance and community.

🛠️ The Cost of Not Fixing It

Open source is the invisible infrastructure of the tech world.

But without new contributors:
• 🐌 Projects stagnate
• 🔥 Maintainers burn out
• 🛑 Critical tech loses support

We’re not talking about missing features, we’re risking missing futures.

🧬 Lost Potential = Lost Innovation

There are millions of devs who want to contribute…

…but don’t know how, or are afraid to try 😞

That means millions of ideas that stay locked.
That’s not sustainable.

🧭 So, How Do We Fix This?

We’re not asking everyone to become maintainers overnight.

But we can make the first step easier — together.
The door to open source shouldn’t feel locked.

🤗 1. Make Projects Feel Welcoming

People don’t contribute to repos — they contribute to communities.

A good README isn’t just technical — it says:
“You belong here.”
• Start with why this project matters
• Add a clear “How to Contribute” section
• Include a real Code of Conduct (humans first!)

📌 MUI’s README is a great example — technical and human.

🧠 People won’t contribute if they don’t feel invited.

📖 2. Docs = Love
Documentation is the first handshake.
Done right, it says: “We care about your time.”

Include:
• 🛠 Setup steps that actually work
• 🧪 Clear testing instructions
• 🧠 A “What to do if you’re stuck” section

Every unclear instruction is a contributor lost.

🐣 3. “Good First Issues” Aren’t a Meme
Tagging tasks with “good first issue” isn’t charity — it’s strategy.

They should be:
• 🧩 Small and self-contained
• 🧭 Explained with real context
• 🔁 Even small things (rename, doc fix) matter

Want to try?
Here are real ones you can do today in vite-plugin-create:
• Add plugin usage example to vite.config.ts — help devs get started faster.
🛠 PR welcome
• Unify default config naming — tiny change, real impact.
🛠 PR welcome

🚀 Where to Find Beginner-Friendly Projects?
Even if you’re not ready to contribute here — there’s a world of welcoming projects waiting for you:
• goodfirstissue.dev 🟢
• up-for-grabs.net 🧩
• firstcontributions.github.io 🎓
• codetriage.com 🧑‍⚕️

Each one helps you discover real issues — not just toy examples — and shows you exactly how to jump in.

No pressure. No gatekeeping.
Just real ways to help. 💪

💬 4. Feedback That Teaches, Not Scares

The way you reject a PR defines your project more than how you merge it.

Bad:
✖️ “This is wrong.”

Better:
✔️ “Thanks for this! Let’s tweak it like this — here’s why…”

Every comment is a moment to mentor. Don’t waste it.

🌱 The Secret? It’s Not About Code

It’s about people helping people.

Want your project to grow?
Help someone grow through your project.

💎 Real Projects Doing It Right:

🟢 Vue.js
• ✨ Clean documentation
• 🧠 Beginner sections
• 🫂 Supportive Discord & community

🎨 p5.js
• 🧑‍🎓 Creative coding for learners
• 🌍 Focus on diversity
• 📦 Tons of beginner-friendly examples

📊 OpenRefine
• 🔍 Clear contribution docs
• 🤝 Active on forums
• 💬 Friendly PR feedback

🌱 My First OSS Step

My journey began with helping a friend build a driving test app for foreigners in Thailand 🇹🇭
He didn’t have time to finish — I jumped in.

Later, we mentored a beginner dev together. It felt like real impact.

Then I tried making a Vite plugin I needed — and published it.

And people actually used it 💥
My first stars. My first issue.
It felt amazing.

That led to more projects. More contributors.
And eventually — my first PRs to React, Vite, and others.

Now I mentor devs and help them start their journey.

🎓 Tip: Take This Course
📚 Open Source Software Development on Coursera
• Clear, practical lessons
• OSS etiquette & licensing
• Real-world Git workflows

If you’re scared to start — this will help.

🤔 And what about you?

I’d love to hear from you — the readers.

🗳️ Have you ever contributed to open source?

Leave a comment with the emoji that matches you:

💡 — I’ve contributed once or twice

🔧 — I contribute regularly

📚 — I help with docs, translations or community

🧍 — I use it but haven’t contributed yet

❓ — I want to, but don’t know how

👇 Drop your emoji below!

🏁 Final Words

🌍 Open source is how we build the internet.
🤝 It’s also how we grow developers, communities, and ideas.

You don’t need to be a genius. You just need to start small — and start together.

✨ The world needs your code. But more importantly — it needs you.

📚 Sources
• Linux Foundation OSS Developer Report (2024)
• JetBrains Developer Ecosystem Survey (2023)
• Evans Data Corporation (2024): Developer Population
• GitHub Octoverse 2024 Highlights
• Vue.js Contribution Guide
• p5.js Community Docs
• OpenRefine Contribution Guide
• goodfirstissue.dev
• First Contributions Project

What’s New in vite-plugin-create v1.0.1 — Or How I Took Another Step Toward the Perfect Generator

Dmitry Titov — Mon, 19 May 2025 01:54:38 +0000

🔥 Highlights of v1.0.1

After releasing the first version of the plugin, I decided not to wait — and jumped straight into building out the roadmap.

The new version of vite-plugin-create isn’t just about bug fixes. It’s a big leap toward full customization. Now you decide what you want to generate, how to name it, and what templates to use — all in a simple, intuitive way.

🧱 Custom Generators

You can now define your own generators in the config:

"store": {
  "path": "stores/{{name}}",
  "files": {
    "{{name}}.ts": "templates/store/zustand.ts"
  }
}

Want to scaffold Zustand stores? Redux slices? A new kind of widget? Go for it.

🧠 Smarter init

The npx vite-create init command now asks:

TypeScript or JavaScript?

And generates a config and template set that fits your stack. No extra files. No cleanup needed. Just your setup — ready to go.

🧩 JSX / JS Support

Working on a pure JavaScript project? No problem. Templates will now match your choice:
•.jsx instead of .tsx
•index.js instead of index.ts

Everything just works.

🎨 Per-Generator Naming Styles

Want your components in PascalCase, but your stores in camelCase? Easy.

You can now configure the file naming style for each generator separately:

"generators": {
  "component": {
    "path": "components/{{name}}",
    "fileNameStyle": "pascalCase",
    "files": {
      "{{name}}.tsx": "templates/component/component.tsx",
      "index.ts": "templates/component/index.ts",
      "{{name}}.module.scss": "templates/component/style.scss"
    }
  },
  "store": {
    "path": "stores/{{name}}",
    "fileNameStyle": "camelCase",
    "files": {
      "{{name}}.ts": "templates/store/zustand.ts"
    }
  }
}

🛠 How It Works

Still dead simple:

npx vite-create init
npx vite-create component MyButton
npx vite-create store userStore
npx vite-create custom whatever

All templates live in the templates/ directory and support Handlebars variables like {{name}}, {{PascalCaseName}}, and so on.

🌱 What’s Next

Here’s where we’re headed:
•🧩 A visual UI to generate and edit your config
•🧪 A playground site with live docs and preview
•🛠️ CLI wizard for adding new generators without manually editing JSON

Conclusion

Plop.js is a powerful tool. We drew inspiration from it. But vite-plugin-create is about simplicity. About zero-config onboarding. About getting up and running with your own templates, your own generators, and working commands — in under a minute.

If you’re tired of boilerplate and want more control with less effort — give vite-plugin-create a spin.

I’d love to hear your feedback and ideas. I read everything.

And hey — see you in the terminal.

📦 GitHub
📥 vite-plugin-create on npm
📝 Original article: How I built a code generator for Vite

What if Vite had its own nest g? Now it does!

Dmitry Titov — Mon, 12 May 2025 03:01:02 +0000

🚀 vite-plugin-create just got a fresh update — v1.1.1 is live!

🧩 You can now:
– Generate standalone files (perfect for hooks, utils, etc.)
– Assign a custom basePath for each generator
It’s a small but powerful step toward more flexible scaffolding.
👉 See what’s new: https://github.com/dimatitov/vite-plugin-create/releases/tag/1.1.1
Feedback and ideas are always welcome — let’s make Vite development faster together 💪

📢 Update — v1.0.1 is out now!

The new version includes: custom generators, JS/TS template support, per-generator naming styles, and more. 👉 Check out the new features and see examples

I’ve only recently started sharing articles and documentation publicly.

Previously, all my writing was internal — release notes, docs, research, roadmaps — all within teams.

But after publishing my first Vite plugin, I felt the need to share it with the world. To get feedback. To see if anyone would find it useful. Maybe someone would suggest a feature, spot a bug — or just say “thanks.”

And while writing about it, I realized something: I enjoy this. I was already thinking about the next topic. But let’s get back to the plugin.

How It All Started: Inspired by NestJS

I’ve been a developer for over 5 years — mostly frontend, but I’ve been getting into backend recently too.

It started with Node.js + Express, and then, at work, we launched a project to automate voice calls and analyze transcripts using OpenAI. I chose to build it with NestJS. I was only mildly familiar with it, but had to dive deep.

And then, I ran:

nest g resource

…and boom — a full module appeared.

I literally said out loud:

“Why doesn’t React have something like this?!”

Yes, there are snippets. Yes, some third-party generators exist. But I wanted structure.

I wanted to type a command — and get a scaffolded component. Just like Nest.

The Frontend Pain

Back to a new internal project: a Telegram Web App using Vite + TypeScript + React + Zustand. A simple, small app.

I start coding, and suddenly I’m back at it again:

Create a folder
Create Component.tsx
Add index.ts
Add props interface
Import styles
…and repeat

Eventually, a new page design landed — and I had to do it all over again.

My eye started twitching.

So I wrote a bash script. It scaffolded everything I needed. Made it executable. Called it create-component.

And you know what? I was so happy.

Then came create-store, create-page, and so on. Life got easier.

But there were still problems:

Every project has slightly different templates
Folder structure varies
Sometimes you need something custom — and have to rewrite the script

Especially on legacy projects — one had Angular 1.5 and React mixed in 😵‍💫

Don’t ask.

Vite Deserves nest g

One day I thought:

“I love Vite. Why not build something like nest g resource — customizable and extensible — for it?”

And so vite-plugin-create was born.

A plugin + CLI to quickly generate components, pages, stores, whatever — from your own templates.

Naming? Customizable. Templates? Yours. Command? One.

Building It: Not As Easy As I Thought

I first warmed up with a simple plugin: vite-plugin-import-alias.

It was smaller in scope, helped me get used to publishing, npm, docs, and user feedback.

But I already knew what the next one would be: vite-plugin-create.

The idea looked simple at first. I had my bash scripts. Why not repeat the same logic, just cleaner?

I imagined:

Templates for files
A config to define structure, names, and naming styles
Catch a CLI command like vite create:component Button — and scaffold away

But then came the disappointment

Turns out, Vite has no API to add custom CLI commands.

So vite create:component? Not possible. I really wanted it to feel native, like nest g, but no luck.

The solution: a custom CLI

I added bin/cli.ts, defined commands, and in package.json:

"bin": {
  "vite-create": "./dist/bin/cli.js"
}

Now, everything runs via:

npx vite-create component Button

Not exactly part of Vite’s CLI, but clean, stable, and simple.

Config & Naming

Next step: how should names be formatted?

Components should be PascalCase — but stores or utils? Maybe camelCase or kebab-case.

So I added a fileNameStyle option in the config:

pascalCase
camelCase
kebabCase
original (leave as typed)

Default is PascalCase, but I plan to let each generator (component, store, etc.) have its own style.

The Config & Templates

One of my goals: make it dead simple and easy to customize.

You shouldn’t need to guess:

“Where do templates go?”
“What format should config be?”

Just run:

npx vite-create init

It creates:

templates/ with a base component
vite-create.config.json with a working example

 {
   "defaultPath": "src",
   "fileNameStyle": "pascalCase",
   "generators": {
     "component": {
       "path": "components/{{name}}",
       "files": {
         "{{name}}.tsx": "templates/component/component.tsx",
         "index.ts": "templates/component/index.ts",
         "{{name}}.module.scss": "templates/component/style.scss"
       }
     }
   }
 }

Templates are just .tsx, .ts, .scss files with Handlebars variables like {{name}}, {{PascalCaseName}}, etc.

 import styles from './{{name}}.module.scss';

 export interface Props {
   className?: string;
 }

 export const {{name}}: React.FC<Props> = ({ className }) => {
   return <div className={styles.root}>{{name}} component</div>;
 };

What vite-plugin-create Can Do (Right Now)

✅ Scaffold any component (or entity) from your templates

✅ Supports .tsx, .scss, .test.tsx, or whatever you want

✅ Works with any naming convention

✅ Lets you define custom generators, like:

npx vite-create store userStore

Or anything you define in the config.

🛣 Roadmap

Here’s what I’m planning next:

✅ Full support for custom generators
🔀 Choose default format: .tsx or .jsx (maybe via — jsx flag)
📁 Template groups — e.g. pages/, widgets/, shared/
⚙️ Per-generator naming style (e.g. PascalCase for components, camelCase for hooks)
🧰 Possibly: a minimal GUI to edit your config visually — in browser or CLI

If you’re tired of boilerplate and repetitive component creation — give vite-plugin-create a try.

Feedback, ideas, PRs — all welcome.

MIT licensed. Open source. Built with ❤️

My First Vite Plugin: vite-plugin-module-alias

Dmitry Titov — Sat, 10 May 2025 19:42:44 +0000

A small tool I built to automate alias config in Vite. Also, my first dev post — feedback is welcome!

🧠 Background

While working on a Telegram bot using a Web App, I chose a familiar stack: Vite + React + Zustand + TypeScript.

Coming from a Webpack background, I found Vite’s resolve.alias handy. But there was a catch: to make TypeScript and my IDE understand the aliases, I also had to configure tsconfig.json. And that wasn’t all — HTML imports didn’t recognize aliases either.

💡 Why Do We Need Aliases in HTML?

Using path aliases in JavaScript/TypeScript (like @components/Button instead of ../../components/Button) makes your code:

More readable
Less fragile to file structure changes
Easier to maintain

In Vite, even if you configure aliases in vite.config.ts and tsconfig.json, these aliases don’t work in index.html — for example, in <script type="module"> tags — because the browser doesn’t know anything about your bundler’s internal setup.

That’s where import maps come in. They allow you to declare aliases directly in HTML so the browser can resolve them correctly:

<script type="importmap">
{
  "imports": {
    "@utils/": "/src/utils/"
  }
}
</script>

This way, your aliases work not only in your source code but also in HTML — no hacks or fragile absolute paths.

🔁 Repeating Myself, Again and Again…

Every time I spun up a new Vite project, I found myself writing the same boilerplate alias configs.

So I thought: why not automate it?

That’s how the idea for a plugin was born — simple, reusable, and driven by a single source of truth.

🗂️ Why an import-map.json?

I wanted something dead simple:

Easy to replicate across projects
No need to configure aliases in 3 different files
Just drop in one config file and you’re good to go

I started with a minimal setup that read from import-map.json, applied aliases via resolve.alias, and injected the <script type="importmap"> tag into HTML — making aliases work even in the browser.

🤔 Why Not Use Existing Plugins?

vite-tsconfig-paths is a popular plugin that automatically picks up aliases from your tsconfig.json.

At first glance, it sounds perfect — but there are a few limitations:

❌ It does not support aliases in HTML — so your index.html scripts still break unless you manually fix the paths.
❌ It depends on tsconfig.json as the single source of truth:
- Breaks the idea of centralized config if you also need vite.config.ts and import maps
- Limits flexibility, especially in template projects or shared configurations
❌ There’s no built-in way to auto-update tsconfig.json when your aliases change — you still have to maintain it manually.

What I really wanted was:

a single config file (like import-map.json),
consistent aliasing in both dev and production,
HTML support out of the box,
and zero setup.

That’s exactly what I built with vite-plugin-module-alias.

🚀 Publishing a Plugin for the First Time

I’d never published a plugin to npm before. Honestly, I didn’t think anyone would care.

But this time, I thought — what if someone finds it useful?

So I cleaned up the code, wrote a quick README, and pushed it to npm.

To my surprise, within a day or two I saw 80+ downloads.

Cool! …Except it had two critical bugs 🙃

🧯 Lesson Learned: Don’t Ship at Night

I made a rookie mistake — released the plugin in the evening with the classic “I’ll fix the rest tomorrow” mindset.

Turns out, “tomorrow” was too late.

Spent 8–10 hours cleaning it up, fixing bugs, improving error messages and docs.

Pro tip: Don’t publish unless it’s rock solid.

🔄 Second Iteration: `tsconfig.json` Auto-Sync

The next logical step was syncing aliases to tsconfig.json automatically.

I experimented with Vite’s server.restart() to reload the dev server, but it wasn’t reliable. So I added two modes:

Auto – plugin attempts to restart the server
Manual – shows a warning to restart it yourself

I also had to deal with relative vs absolute paths, JSON formatting, and edge cases.
Big thanks to my small group of early testers (you know who you are!).

🧩 My First GitHub Issue 🎉

One day I got a GitHub notification — my first issue!

It felt like a milestone.

Luckily, it was a small bug and only took 10 minutes to fix. But seeing someone using the thing — and caring enough to give feedback — was amazing.

🧱 The Unresolved Bit: JSON Comments

One challenge remains: preserving comments in tsconfig.json.

Standard JSON parsers strip them, and I haven’t found a reliable workaround yet. I’m still experimenting with different solutions.

If you know of a solid fix — PRs welcome 😉

🔭 What’s Next?

I’m planning to:

Improve documentation
Add better error handling and validation
Maybe support YAML configs?

Links

🔗 GitHub: vite-plugin-module-alias
📦 npm: vite-plugin-module-alias