{"id":20476,"date":"2020-09-02T23:13:23","date_gmt":"2020-09-02T23:13:23","guid":{"rendered":"https:\/\/rbsitsoftwaresolution.com\/blog\/how-to-judge-open-source-projects.html"},"modified":"2020-09-02T23:13:23","modified_gmt":"2020-09-02T23:13:23","slug":"how-to-judge-open-source-projects","status":"publish","type":"post","link":"https:\/\/www.rbsitsoftwaresolution.in\/blog\/how-to-judge-open-source-projects.html","title":{"rendered":"How to judge open-source projects"},"content":{"rendered":"

Plenty of people have put together systems to collect, judge, and evaluate open-source projects, including information about a project’s popularity, reliability, and activity. But they all have flaws.\u00a0<\/p>\n

Take that oldest of metrics: Lines of code (LoC). Yes, it’s easy to measure. But it’s also profoundly misleading. As programming genius Edsger Dijkstra observed in 1988, LOC gives us “the reassuring illusion that programs are just devices like any others<\/a>, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring ‘programmer productivity’ in terms of ‘number of lines of code produced per month.’ This is a very costly measuring unit because it encourages the writing of insipid code.”<\/p>\n

We got better since then, haven’t we? Maybe not.<\/p>\n

Take GitHub Stars<\/a>, for example. GitHub<\/a>, the biggest open-source Git repository, describes these as just a way to keep track of projects people find interesting. But many developers see them as a way of measuring an open-source project’s popularity <\/a>and reputation. In short, the more stars, the better the program. Or is it? \u00a0\u00a0<\/p>\n

Just listen to Solomon Hykes, Docker<\/a>‘s co-founder: “GitHub stars are a scam.<\/a> This bullshit metric is so pervasive, and GitHub’s chokehold on the open-source community so complete, that maintainers have to distort their workflows to fit the ‘GitHub model’ or risk being publicly shamed by industry analysts. What a disgrace.”<\/p>\n

Hykes isn’t the only one who sees them that way. Fintan Ryan, a Gartner<\/a> senior director, calls them a game, which many projects play<\/a>. Microsoft project manager for open-source development on Azure, Ralph Squillace, tweeted: “In my opinion and for Microsoft project eng and management they are worthless<\/a>. [But] There are always people who seize on them anyway.”<\/p>\n

And that’s the problem. People love easy metrics. They want a quick, one-glance answer to their coding problems. Spoiler alert: There is no such thing.<\/p>\n

\n<\/section>\n

It would be great if there were such a thing. In 2005, open-source was already taking over the developer world.\u00a0Red Monk<\/a> analyst Stephen O’Grady observed that open-source software was taking over the enterprise<\/a> in a major power shift. So can anyone really be surprised that Red Hat<\/a> recently found that 95% of enterprise IT leaders thought open-source software was “strategically important?”<\/a> But an easy way to work out which of the tens of thousands of projects are the vital, important one, a software Yelp<\/a> if you would, doesn’t exist. It may never.<\/p>\n

Sure, we can identify the most important open-source projects. Some are tech household names such as Apache, Firefox, and Linux.\u00a0<\/p>\n

Or can we? Others — and this should concern you — are vitally important but hidden<\/a> as components deep inside more well-known programs. In a 2020 study, Vulnerabilities in the Core<\/a>, The Linux Foundation<\/a>‘s Core Infrastructure Initiative (CII)<\/a>, and the Laboratory for Innovation Science at Harvard (LISH)<\/a> discovered that the most commonly used programs include such unknown (except to developers) components as Com.google.guava; Httpcomponents-core; and Lodash.\u00a0<\/p>\n

To find these, they used Software Composition Analysis (SCAs)<\/a> tools from developer security companies Snyk<\/a> and Synopsys Cybersecurity Research Center<\/a> to take deep dives into tens-of-thousands open-source codebases. This is not trivial to do. But it’s the only way to determine what code functions really are popular and frequently used.\u00a0<\/p>\n

An easier way to determine an open-source program’s quality is simply to look at the number and quality of its developers. Mike Volpi, a well-known venture capitalist and Index Ventures<\/a> partner, said that since “software is never sold,” it is adopted by the developers who appreciate the software more because they can see it and use it themselves rather than being subject to it based on executive decisions.” Therefore, “open-source software permeates itself through the true experts,” and . . . “the developers . . . vote with their feet.<\/a>“<\/p>\n

If the programmers are leaving, the maintainers aren’t getting back on patch requests, and the code is growly moldy, it’s time to bid that program good-bye. Or, if it’s essential to you, take it over yourself.\u00a0<\/p>\n

You can also determine a project’s health by how easy — or not — it makes it for others to participate in it. Ed Warnicke, a Cisco Distinguished Consulting Engineer, believes successful open-source communities lower the barriers to useful participation. He lists many barriers to participation, which are red flags. These include:<\/p>\n