How Should an Open-Source Maintainer in Spain Present npm, PyPI, GitHub, and Documentation Work?

An open-source maintainer should create one project entry per maintained package or coherent tool, state their role, show its current maintenance status, and link to the source that best helps a visitor evaluate it.

npm and PyPI describe releases, GitHub shows code and activity, and documentation explains use. The portfolio should not copy all three. It should identify which projects matter, whether they are maintained, and where a reviewer should go next.

What counts as one open-source portfolio project?

Treat a package, library, CLI, or tightly related family as one project when it has one purpose and one maintenance story.

Do not create separate cards for its registry page, repository, docs, and examples. Use the project description to explain the problem it solves and your role—creator, core maintainer, contributor, or documentation author.

Forks, tutorial exercises, and tiny patches should appear only when they add relevant proof. A concise maintained set is more useful than a generated list of every public repository.

What is the fast way to organise packages with IndieShow?

The fast way is to add each meaningful open-source project to IndieShow, tag it by ecosystem, and group it by maintenance state.

Use Shipped or Built for stable work, Building or Working on for active pre-release tools, and Archived for packages you no longer maintain. Add a logo when the project has one and an optional metric only when it is current and verifiable.

Reorder the list for the audience: the most relevant package for a Python role can lead even when an npm project is newer.

Build your IndieShow pageClaim a handle, organise the projects in the editor, and review the $15 one-year and $30 lifetime publishing options in the dashboard.

Should the card link to the registry, repository, or docs?

Link to the destination that answers the reviewer's likely next question with the least friction.

Choose documentation when adoption and usage matter, the repository when code and maintenance matter, and the registry when installation and released versions are the main proof. Test that the destination is public and current.

Mention other surfaces in the project description only when useful; IndieShow provides one destination per card, so make that choice deliberately.

How do you show maintenance status without misleading users?

Use a current status section and plain language that distinguishes active maintenance, feature development, stability, and retirement.

A stable library with few commits can still be maintained, while a busy experimental repository is not necessarily production-ready. Do not infer quality from download counts or badges; explain what you actually support.

The related portfolio and archive guides cover ordering large bodies of work and retaining retired projects responsibly.

Useful IndieShow guides: building an indie hacker portfolio · showing archived work without harming the portfolio

How does IndieShow create a stable maintainer identity?

IndieShow gives the maintainer one personal URL where packages can be reordered, updated, and archived without changing the link already shared.

The registries, repositories, and docs remain authoritative. IndieShow sits above them as the maintained index that tells recruiters, users, sponsors, or collaborators which work represents you now.

Close with a clear role for every highlighted project and remove dead destinations. That is more credible than presenting ecosystem activity as if every repository were an owned, supported product.