

How you know your open source software project is doomed to fail - prog
http://spot.livejournal.com/308370.html

======
epochwolf
I find this interesting. I have a few nitpicks for everyone's consideration.

>* The source code is more than 100 MB.

Excluding images, example usage, and generated documentation, sure.

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

Installing to /usr/local is the accepted default for linux. Plus, I actually
use the package manager on my system. I want compiled software to install to
/opt or /usr/local so I can find it later and remove it if necessary.

Now trying to install to /opt on windows is just stupid.

>* Your code does not have per-file licensing [ +10 points of FAIL ]

This is pedantic. If the entire codebase is under the same license which is
given as LICENSE in the program's folder you're good. (You should make it
clear in README that LICENSE does apply to the entire project.) If not, any
inconsistent licensing should be _explicitly_ defined either in a visible top
level document next to LICENSE which lists each exception clearly (e.g. stuff
in multiverse/ is proprietary, see multiverse/<project>/LICENSE for details)
or at the top of each file that doesn't match the license in LICENSE.

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

I think this one bothered me the most. `/usr/local` is the _correct_ default
location for user installed software, per the "Filesystem Hierarchy Standard".
If the software's static file must be contained in a `./<package>`or
`./<provider>` directory (vs bin, lib, share...), it should probably go in
`/opt`.

~~~
epochwolf
Ah... I see. Nginx likes to install itself to /usr/local/nginx which isn't
correct per FHS. It should install to /opt/nginx.

~~~
ominous_prime
Yeah, but since /opt isn't always created by default on all systems, I don't
think it's that big a deal. You can almost always count on /usr/local being
there. As long as they don't go and dump stuff in /{bin,lib} or
/usr/{bin,lib}.

------
c00ki3s
>* You've written your own source control for this code [ +30 points of FAIL ]

Linus Torvalds wants to have a word with you.

~~~
loup-vaillant
Considering that the Linux kernel hardly is the sole user of Git, these 30
points hardly apply.

Conversely, Emacs certainly deserve a few fail points for being the sole user
of its programming language (Emacs Lisp).

~~~
docgnome
Not really sure what the Emacs jab has to do with anything. It's a bit like
comparing apples and Godzilla.

~~~
loup-vaillant
Well, "rolling your own programming language" wasn't mentioned in this fail
list, but I feel it could have been, since build systems and vcs are
mentioned. Hence the fail points for Emacs. Now, it can also yield win points
for using an especially well suited programming language.

(Bye the way, I love Emacs)

~~~
eru
Unix came with its own programming language.

------
jmillikin
More proof that people who uses the word "fail" as a noun have few opinions
worth listening to. Using his criteria, are there _any_ major F/OSS projects
which are not "So much fail, your code should have its own reality TV show"?

~~~
jpr
There probably aren't. I don't know if tells more about the projects or the
state of software in general. I'd bet on the latter.

------
patio11
I am interested in hearing the considered thoughts of HNers about how one
could optimize the experience of developing (as opposed to consuming) OSS in
such a way as to improve the chance the project would succeed, but virtually
any article would be a better starting point for discussion than this one.

~~~
wmf
I like the book _Producing Open Source Software_ : <http://producingoss.com/>

------
jimfl
Your code assumes it is running in a POSIX environment [+20 point of FAIL]

~~~
cperciva
Assuming that you're running on POSIX is pretty safe these days. Even Windows
has a POSIX compatibility layer.

I'd go so far as to say that being able to build and run in a POSIX
environment without needing any platform-specific configuration (or
autoconfiguration) is worth at least 20 points of WIN.

~~~
aidenn0
Having ported (or attempted to port) significant quantities of FOSS code to a
fully POSIX conformant OS that is not windows/linux/bsd, I feel pretty
comfortable stating that there are no non-trivial FOSS programs that do this
(and 99% of all very simple "do just one thing" UNIXy programs don't).

------
cdibona
And yet, the kernel and chromium are excellent codebases under healthy and
active development and are running on tens or hundreds of millions of
machines. We should all 'Fail' so well.

People are happy to rant and rage, but the value of these large projects
persists.

------
igorgue
My score for Chromium is: "65-90 points of FAIL: Kittens die when your code is
downloaded"

------
zackattack
I'm turning hip hop goblin into an open source project and I could use a
mentor as I have never been involved in open source before. I have many
questions. For example: how do we keep track of which person is working on
which task, such that people's efforts aren't being duplicated?

I put the source on Github btw- <http://github.com/zackster/hip-hop-goblin>

~~~
DCoder
You're looking for an issue tracking system / bugtracker. Try the Issues tab
on github. You create an issue/task that needs to be done, assign it to a
developer, and ask them to update the issue's details as he/she progresses.

I am not that familiar with GitHub, so I can't give you specific instructions
or examples, but the project I'm working on uses Mantis for this, and it works
a treat - we integrated it with SVN and now svn commits create new Product
Versions, revision commit messages are automatically posted as issue comments
+ issues get marked as "resolved" if applicable, changelogs for latest
changes, roadmaps for future plans, etc.

~~~
zackattack
Thanks. Apparently you can't delete issues on Github? Weird.

~~~
boucher
I love Github, I like the Github team, and I use Github issues every day. But
I honestly can't wish it on anyone else, it's just terrible. It's slow, buggy,
and not all that well organized.

