From my time exploring and using a range open source and/or self-hosted projects I’ve built up a range of known “amber flags”. I hesitate the call these reg flags, as by themselves I don’t think they’re specifically problematic, but they usually act as indicators of projects that aren’t aligned with my personal ideals in software I look for.
Note: These are very much personally opinionated, and this is not a dig at any project which just happens to have such flags, they’re really just an indicator used as part of a general “sniff test” against my ideals.
Also, this is about the higher level project elements (licensing, marketing etc…) that I consider before digging deeper into code.
Being able to see the UI of an application can tell a lot about a project, from its development completion, to its design intent. Not being able to quickly understand the visual appearance of a project is an instant turn off, as that leaves a high level of friction (typically downloading & building the project) to understand if the project is what you expect or need.
If build instructions are not obvious from the project root folder or readme, I’m immediately going to get sceptical as to if there’s a reason they’re missing. Can the project actually be built from source provided? Does the owner not want folks building from source for some reason?
Breaking changes are inevitable given enough time. If a project is lacking readable & accessible update notes, then it brings into question how you’ll know or consider breaking changes. Reading past notes can also provide an indicate of development progress, stability and potential future update effort.
Ideally you should be able to get a full idea of licensing for an entire project with a quick glance of a file. Quite often, especially in “open core” projects I’ve seen this made much more complicated to the point where you’d have to look across all project folders. Dynamic licensing can also mean that changes to licensing can be made in sneakier ways. Here’s some generalized examples of the kind of complexity I’ve seen in licenses:
Licensing can be a complex subject, and licenses themselves can be tricky to understand, but it’s not uncommon to see projects (especially those growth/commercially focused) misrepresent their license and/or label themselves as “open source” without providing open rights of use, modification and distribution. I talk more about this here and here, and I track cases of this kind of thing here.
A growing scenario of licensing misrepresentation is where the project is advertised as open source, but the open source offering actually directly relies on code under a proprietary non-open license, and therefore can’t be fully built/used as open source without manually patching-out/replacing proprietary parts. This is something I’ve written more about here.
These are amber flags for small/early projects, who I give the benefit of the doubt to since this might be their first encounter with licensing, but to be honest it’s a big red flag for established projects.
GitHub stars can be useful as a general self-relative growth metric, but they’re often desired to gain an (inaccurate) indicate of project popularity/value. In my view though they don’t indicate value, but hype and marketing aggression. I’ve seen them heavily referenced in VC-targeted slide decks to try to impress potential investors.
If I see a project strongly chasing stars, it’s an indicator that the project may be looking to pump their count for growth & sell potential. Large GIFs, showing how to star the project, are a personal common pet-peeve as it just comes across condescending for little value. I also see a lot of “Star the project to keep updated” types of notices, which I see as quite misleading in most cases and likely just an attempt to gain more stars, since the actual built-in GitHub feed functionality for this is fairly unknown & unclear. They could be scanning stargazing users, then scraping your personal email from your GitHub profile page, but I never see that mentioned so such use of personal info would be an extra flag in itself.
In a way I still use stars as an indicator but combined with project maturity along with total open & closed issues. If a sizeable project has a big star count but only has a few hundred total issues, that’s a sign of hype and/or growth-focus.
Marketing is one of those things that kind of has to be done to get your project out there, but while spending (way too much) time on Reddit I’ve seen quite a number of what I’d consider sketchy marketing practices. This includes:
If I see a “We’ve raised x million!” banner or post, I quickly get suspicious. I realize that funding can really help a project, but it’s often an indicator of change. A potential change of leadership, change of licensing, change of offering… When a lot of money is raised, I can’t help that feel that pressure is also raised. Pressure to succeed, pressure to return. What I value looking at a project may not be what they value when it comes to making hard decisions & changes under that pressure.
Project blog posts can be a great way to provide updates and insight regarding a project. Sometimes though you’ll see a project spewing daily, or even multi-daily, blogposts regarding anything even mildly tangentially related to the project, often being of low value guff. This is really just SEO focused growth hacking and indicates a priority of growth over value.
This is again related to “Open Core” projects. I think open core can be done well, where the open and non-open offerings have clear separation to provide users with a clear indication of what’s in each, but it’s unfortunately too common that projects will freely mix these up under the same name, pushing their open offering to communities while being very much limited or full of banners/advertisements pushing users to paid offerings. Having arbitrary hardcoded limits (users, teams, etc..) is usually an immediate indicator of this.
Too often I’ll see projects posted to the /r/selfhosted subreddit, only to then see that they require specific external services for core functionality. Vercel and Firebase are big frequent dependants.
There’s usually two different drivers behind this:
A website can quickly indicate if a project is prioritized on the “Enterprise” use-case, rather than the sole hacker/hobbyist like me, which often means their goals/ideals are not too aligned.
A big indicator can be if you can’t easily find the source or a download link. If you have to fill a form with your personal details, or hunt around for the source, that’s usually a sign other common things will be more hassle. If their homepage lists case-studies, logos and links to whitepapers, instead of showing screenshots/examples/code, that’s usually telling of misaligned ideals.
Outside of enterprise-heavy apps as mentioned above, “The Whitepaper” seems to be popular in the land of crypto based applications. One such application I come across claimed to “solve open source funding”, but when asked exactly how it achieves that, I was advised it’s all explained in the whitepaper. If your value has to be explained in a 50 page PDF, instead of a single paragraph, I’m going to assume you’re actually trying to confuddle up some pretend value.
To be honest I’ve never understood Product Hunt. Looking at projects on there, the comments always seems to be a bunch of tech bros circle-jerking each other’s projects with a bunch of over-enthusiasm and keywords. Ultimately, it’s just another list folks try to get to the top of for marketing clout. If a project is actively pushing their Product Hunt “launch” in external communities, or adding big banners to it from their site or readme, it again reflects a priority of using a community for marketing rather than focusing on the project/value. They’re diverting attention in the hopes of artificially inflating themselves up a list full of others playing the same silly game. Quite often this may be part of a “lunch week”, which is another spanner in the growth-hacker’s toolkit for driving hype.
So those are my “Amber flags”. I’d be interested to hear what other things folks may consider in the self-hosted and open source space.
While writing this I did wonder if this is a pessimistic way to review projects, but that might be a matter of perspective. It does feel a bit negative with these listed out all at once, but in practice I enter a project optimistic, then pick up on these factors as I review it further.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。