How to tell if a FLOSS project is doomed to Fail (2009) | Hacker News Reader

How to tell if a FLOSS project is doomed to Fail (2009)

theopensourceway.org

20 pointsingve8 comments

> Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]

I thought these were the canonical directories to install software. Is the idea here that the directory should be specified by the user during the build?

Yes, make DESTDIR=/poop install or configuring ./configure --prefix=/fart. You are supposed to be able to even combine them, e.g. the above would be installed to /poop/fart.

I think the main reason most /useful/ projects fails have to do with the initial user experience:

1- Is it easy to get started and installed?

And that if the project pass the basic test that applies to any project, company or software:

2 - Is it useful and solves a problem?

If it is useful and people can actually get started on it, the project has good chances of doing well.

    If documentation exists on how to build from source, but it doesn't work [ +10 points of FAIL ]
    Your source is configured with a handwritten shell script [ +10 points of FAIL ]

Most projects I've ran into fall under these categories. As soon as I see a Makefile I know I'm going to spend two hours hunting down libraries or hacking in macros. it's very frustrating.

    Your source builds using something that isn't GNU Make [ +10 points of FAIL ]

I've had less headaches with cmake, and it solves (most) of the first issue. In general I'd recommend cmake over make.

There's been many times I've wanted to submit a one line pull request, but I doubt my self too much to use gitlabs code editor. After a few hours of trying to compile I'd just give up.

Your code only builds static libraries

Therefore, all projects in Go are doomed to fail. Somehow, I think not!

Go makes you depend on the source code of a library you're depending on, not any build result. Because Go by default does not generate shared libraries to ship, they work around this by having every user of a library recompile it into their project. They avoid compiler mismatch issues by doing this.

So no significant open source Go library provides static libraries to their consumers. They provide source code. I think this list holds up very well, but there are several go projects that have had serious impediments due to things on this list.

The obvious example being the bane of my existence - the $GOPATH. The amount of effort Go projects have to put into getting some half-assed version of `make dist` to ship a tgz is depressing.

Quite informative! Thanks.

OpenOffice...

Reply on news.ycombinator.com