Our methodology
How We Evaluate Open-Source Software
Choosing open-source software involves more than finding a free alternative.
You need to understand what a project does, whether it meets your needs, what it takes to run and maintain it, and what the real costs might be.
At Next Level Open Source, our goal is to make those decisions easier through practical explanations, relevant sources and transparent comparisons. This page describes how we aim to do that, and what our project pages do today.
Useful Information. Honest Comparisons. Informed Decisions.
We evaluate projects from the perspective of people who want to use them, not just browse a list of features. Three principles guide how we want project pages and guides to help you decide.
Practical usefulness
Explain what the software does, who it is for and which problems it can solve.
Transparency
Make limitations, technical requirements, additional costs and important trade-offs visible.
Evidence
Use relevant sources, prioritise official documentation and distinguish sourced facts from estimates or editorial judgement.
What We Look At
Seven areas, each with what we aim for and what our project pages do today.
Purpose and Capabilities
Explain the problem the project is designed to solve, its core functionality and the people it is intended to serve.
Distinguish between features documented by the maintainers, features that have been independently tested and features that have not been verified.
On our pages today: Every feature on a project page is quoted from the project's own website or documentation, with a link to the page it came from. We have not independently tested any features yet, so none is presented as tested.
Alternatives and Limitations
Identify which paid products may be relevant alternatives, considering meaningful differences in functionality, integrations, usability and intended audience.
Two products are not equivalent just because they share a category. Where the evidence supports it, we explain significant gaps.
On our pages today: We name a paid product when the project's own pages compare themselves with it; if they name none, our reviewer chooses one. Pages say whether a project covers some or most of what the paid product does, or that this has not been assessed; never that it replaces it completely. They also list what to look elsewhere for.
Licence and Usage Rights
Identify the licence from a relevant source, preferably the repository's licence file or official documentation.
Open-source licences have different conditions and obligations. We do not treat them as identical, and we do not give legal conclusions about your specific use.
On our pages today: Pages show the licence as GitHub reports it, marked "per GitHub, not checked". No person has reviewed the licence files themselves yet. If GitHub reports no licence, we stop and look into it before adding the project.
Maintenance and Project Activity
Look at indicators such as recent releases, repository activity, issue responses, documentation updates and maintainer communications.
Activity is a signal, not a guarantee of quality, security or long-term support.
On our pages today: Pages show the latest release, the date of the last change to the code, the age of the repository, and star and fork counts for the last 30 days, recorded from GitHub every day. We do not yet track responses to issues, and we do not give maintenance scores. If a repository looks like a fork, a mirror or an archived project, we stop and check before adding it.
Installation and Technical Requirements
Identify the supported ways to run a project, such as installing it on your computer, Docker, your own server or a hosted service, and what each needs: operating system, dependencies, server resources, databases, skills and external accounts.
We only list an installation method when the project's documentation describes it.
On our pages today: Each way to install comes from the project's own installation guide, with its requirements. Difficulty uses one scale: easy (an installer, or one command that starts everything), moderate (your own database, a settings file or a secure web address to set up), advanced (building from source or several services to connect). Setup prompts send you to the official guide rather than giving commands of our own.
Running Costs
Separate the software licence from the total cost of operating the software: hosting, paid API usage, storage and bandwidth, domain names, commercial integrations, maintenance, backups and monitoring.
Show the assumptions, usage level, pricing source and date checked for every estimate, and never call software free to run unless the usage scenario justifies it.
On our pages today: Monthly estimates for light, typical and heavy use are built from official price pages; the source and the date each price was read are kept on record. Hosted plans are copied exactly as the project writes them. A $0 figure appears only when the project itself says the software is free to use and nothing else needs paying for. Electricity is not included.
Security, Privacy and Dependencies
Identify relevant considerations from official documentation: data handling, permissions, external services and dependencies, and whether you need to provide credentials, connect third-party accounts or send data to external APIs.
A project is never presented as secure, private or audited without evidence, and missing security information is an information gap, not proof that a project is unsafe.
On our pages today: Project pages do not include a security or privacy review yet. Where a project needs an API key, a paid data service or an external account, its page says so.
Where Our Information Comes From
We build project pages from information you can check yourself. Depending on the project, sources include:
- Official project websites and documentation.
- Source-code repositories and their licence information.
- Release histories and maintainer announcements.
- Official pricing pages for hosting, APIs and related services.
- Installation guides and configuration requirements.
- Product pages of the paid alternatives.
We prioritise the source that is authoritative for each claim. The repository is the right place for release history; a provider's own pricing page is the right place for its current prices. Third-party articles and community discussions can give context, but they do not replace official sources. Where a claim cannot be supported, we do not present it as fact.
How a project is added today: a person chooses an open-source project from its GitHub repository. We save copies of its official website and documentation pages, then write the page so that each statement is backed by a quote from those saved pages. A check refuses any quote that does not appear on the saved page. GitHub numbers come directly from GitHub. A person reviews the whole page before it is published.
Free Software Does Not Always Mean Free to Run
A project's licence cost is only one part of the decision. Some projects run on your own computer with little extra expense; others need servers, external APIs, paid integrations or ongoing infrastructure. Our goal is to make the assumptions visible.
- Software licence
- Whether the software is available under an open-source licence, and whether the licence itself requires payment.
- Minimum running costs
- The services or infrastructure needed for a basic supported setup.
- Typical operating costs
- Illustrative costs for a stated usage level, where pricing and resource information allow it.
- Optional expenses
- Paid integrations, higher service tiers, more storage or other extras that not every user needs.
Cost estimates are not guarantees. Actual expenses depend on usage, infrastructure choices, region and price changes. When there is not enough evidence for a meaningful total, the page says what is known and does not show an estimate.
Information Changes. Our Evaluations Should Reflect That.
Open-source projects evolve. Features change, new versions are released, licences may change and providers update their prices.
For each quote we keep the date we saved its source page. When a person approves a page for publishing, each quote also records the day they checked our wording against that source: an actual check, not the date the page was published or edited. Project pages show these dates in their full source lists. Running-cost prices are stored with the date they were read.
Star and fork counts are updated automatically every day. Other information is not monitored automatically, and there is no fixed review schedule yet: a page is updated when we review it again, or when an error is found.
Facts, Estimates and Recommendations Are Different
Not every part of an evaluation has the same level of certainty. We aim to keep four kinds of information apart:
- Documented facts
- Information supported by the project's documentation, its repository records or another appropriate source, with a link to it.
- Estimates
- Figures calculated from stated assumptions, such as monthly running costs. They are labelled as estimates.
- Editorial assessments
- Our interpretation of how suitable a project may be for a use case, skill level or budget, such as "Is it right for you?".
- Unknown or unverified information
- Details we could not establish from the available evidence. Pages mark these as "Not checked yet" rather than guessing.
A recommendation can be useful without being right for everyone, and an estimate can be informative without guaranteeing the final result.
Recommendations Should Serve the Reader
Our aim is to help you find tools that suit your needs, skills and budget. Comparisons and recommendations should rest on relevant criteria and the available evidence, with important limitations made clear.
We do not currently use affiliate links. If we add affiliate links or other commercial relationships, we will disclose them clearly, and they will not be presented as evidence that a product is better than its alternatives.
Help Us Improve the Information
Open-source projects change, and information can become outdated or incomplete. If you notice an incorrect feature description, outdated pricing, a licence discrepancy or a broken installation guide, we want to know.
Please include the project name, the page concerned and a source or explanation of the issue. We will review it and correct the page where needed.
A contact page for reports is being prepared and will be linked here.
Find the Right Tool for Your Next Project
Explore open-source alternatives, understand the trade-offs and discover practical ways to get started.