
How to tell if a FLOSS project is doomed to Fail (2009) - ingve
http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html
======
88e282102ae2e5b
> 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?

~~~
codemac
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.

------
rmdoss
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.

------
pippy

        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.

------
stcredzero
_Your code only builds static libraries_

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

~~~
codemac
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.

~~~
stcredzero
Quite informative! Thanks.

------
chris_wot
OpenOffice...

