If your project is meant to be open source and it's addressed to the community, whether you like them or not, it's good to follow the "standards" or common practices adopted by the community for your specific stack.
Even if it's not OS, it's good to adopt them, especially if someone else has to work on it.
If you dislike the way the community organise code, ignoring this and going your way could make possible collaborators to feel uncomfortable and don't adopt your project. Some things are assumed as "standard" by many. For one reason or another, the community adopt some practices and assume they are going to be this way by default. That encourage 3rd parties to implement tools that take these practices as "defacto standards" and build their functionalities upon them. Think about how Maven imposed the basic project structure in Java projects. Or how SCMs as
Git has encouraged the use of markdown files like README.md or CHANGELOG.md in the root. The think about those plugins for Jenkins that look for java binaries in
target/classes after the build.
As @Amon commented, in the end, it's up to you to agree with these practices and follow them. Just bear in mind that ignoring them could make your job unnecessarily complicated. For example, by having to twist the IDE configurations or setting up uncommon env vars just because nothing is where it's expected to be by default. I would not expect too much support form the community when things go wrong either.
Q: Best practices?
I encourage you to adopt the concrete practices and conventions of the community for your technological stack. It will make easier for you to find support when need it and probably it will ease the instrumentalization of the SDLC through tools that assume you are following the conventions.
Q: How can I make a clean and clear structure?
Directory tree aside, there are some well-known strategies to organize the source code. These are related to the packages|namespaces (for some languages this is tightly coupled to the directory tree too). I'm speaking about the package by feature, package by component or package by layer. From the development (and developer) standpoint, these are more valuable when it comes to clean code. Definitively, we developers don't' navigate through folders. We rather navigate through namespaces or packages (most of the time I mean).
From an architectural standpoint, one rule is keeping unrelated things separated. The more unrelated the more separated, from different folders to different projects and hence different repositories.
From the SCM standpoint. Well, Github, Gitlab, Bitbucket have lookups and browser to look for files and contents from the web console.