How to Ruin Tiki


A link to a very clean and concise presentation on "99 Ways to Ruin an Open Source Project" was posted to the devel-list and some people recognized some of the ways being present in the Tiki community. This page is to collect them to keep us on our toes. If something in the presentation feels too familiar, then add it to this page with a brief comment as to why.

#18 Use +1 as much as possible.

In the Tiki community you see +1 being used just about anywhere and it nowadays actually doesn't mean jack. Some people even give +100 or similar, clearly stating this way that they don't understand what +1 means.

#33 Require excessive configuration

The flip side of "make everything optional"

#34 Make releases unreliable

Maybe not unreliable exactly, but weak on bug fixing and testing (including me!)

#45 Use a LICENSE that is inappropriate for the intended use.

Tiki is not a library and we do frequently have problems with desired libraries being GPLed. Can't do much about it any more, but it belongs on this list.
I feel this section should be removed because LGPL is a good license for Tiki. Any license has incompatibilities with other licenses. GPL does not want to work together with anything non-GPL, we would not want to be in this situation.The L from LGPL stopped meaning library for decades. LGPL is a good compromise between licenses which are open-source without attempting to support open-source (BSD-style) and licenses which are not interested in linking with anything else (GPL)

#48 Have as many dependencies as possible.

Tiki is huuuge. With lots of things being added by composer. It's composer and that helps, but yeah.

#52 Prefer clever code over clear code.

There are some parts of Tiki that are just incomprehensible without a Ph.D. in computer science and a one week bootcamp about how fancy some developers' brains are.

Page last modified on Thursday 13 August 2015 08:26:25 GMT-0000

Upcoming Events

No records to display