The following is an answer to the insightful post by Petr Gladkikh on the PicoLisp Mailing List.

Hi Petr

Many thanks for your participation and outside view.
Such comments are very valuable to us, as those topics are hard to see from the inside.

I believe those feelings are triggered by mainly two source factors:
A) presentation of picolisp information
B) the (rather unusual) state of the picolisp project

A) First and foremost, we as community need to streamline our presence more,
probably mainly by making things more clear on picolisp.com.

We should also more prominently point to the IRC channel, that is where we meet daily.

Online repositories like https://github.com/taij33n/picolisp and https://bitbucket.org/mmamkin/picolisp are not mere personal forks, but up to date clones of the official release at http://software-lab.de/picoLisp.tgz
Both taij33n and mmamkin are core members of the picolisp community.

Petr, would it help if we would link and describe those repositories prominently on picolisp.com ?
Or do you think people don't go first to our website, but find it directly on github/bitbucket and are turned away when they see "0 contributors" there?
Maybe putting a prominent note into the readme at github/bitbucket could improve this a bit...

For years, PicoLisp used to be hosted in such a online community, actually at Google Code.
There are two main reasons why PicoLisp development is not anymore managed over such a service:

1) Google Code closed down. Yes, its unlikely that this will happen soon with Github, but such offerings from big commercial companies are always up to the moods and motivations of the company, which can change suddenly.
As a user, you're their asset, not the other way around.
The philosophy of PicoLisp is to stay in control, for long-term stability, instead of short-term comfort by introducing dependencies.

2) In case of PicoLisp, the benefits such services bring (except more visibility) are actually not needed for core PicoLisp. For reason B), because...

B) PicoLisp is finished software
It is old (over 30 years), well tested (in real world usage), stable and secure.
Much more knowledge, both programmer experience and usage experience, has already gone into PicoLisp compared to all those fashionable young projects which mostly just were started very few years ago.

We have 4 types of issues with picolisp:
1) Programmers does not see how to do something (easily). Does it wrong or demands a feature.
Someone (nearly always Regenaxer, we need to improve here as a community) invests time to explain the guy how it can be easily done with x,y.
Nearly all issues fall into this type.

2) Some incompatibilities on unusual platforms (e.g. running PicoLisp on BSD or Solaris) - usually fixed within hours or days by the guy who asked and by the community, often even without involvement of Regenaxer.

3) Someone comes up with a request for a feature for special use case which really doesn't fall into type 1), e.g. Mike/tankfeeder came up with requirements for some special functions to do his expert algorithm and crypto stuff.
Such requests are acknowledged and implemented by Regenaxer in few hours or few days. Usually this all happens in IRC, or in mailing list.

4) Real bugs
Very rare, actually they are only found in special edge cases which only show up with unusual intensive usage.
E.g. there was once a special bug in a rarely used binary operation function, or also stuff like solvable (previously not well-known) architectural limits like the 500-process limit on a fully interconnected picolisp process family (when using PicoLisp-internal IPC, the cause is OS limits on the number of file descriptors).

Therefore there is no need for any actual bug tracking management - though an issue tracker which functions more like a dev FAQ, a collection of problems and solutions, might be an improvement.
On the other hand, that exists on rosettacode.org! http://rosettacode.org has PicoLisp solutions for all common tasks.

PicoLisp still gets new features, but those are special purpose features, or high-end optimizations of the existing features - or new platforms. But the core is not changing much.

What we surely do need:

• better documentation: the language reference is complete, but library code and some tooling are only partially documented
• more hand-holding tutorials
• more pointers towards IRC chat (#picolisp on freenode.org)

This all could be done by newcomers even.

Does this answer some of your concerns? What can we do to improve our communication? Other issues?

Kind regards, beneroth