Snap Wiki: https://snapwiki.miraheze.org/wiki/Main_Page
Snap has many libraries that you can get from `File/Libraries…
It has a forum. What else do you want?
No-one (I think) plans to change the GUI from the 1.4 style. You could fork it if you want.
If you know how to use github, you can submit a pull request to https://github.com/jmoenig/Snap, (IDE) https://github.com/snap-cloud/snapCloud, (cloud program) or https://github.com/snap-cloud/SnapSite. (static and dynamic pages on the site)
Snap! uses Morphic.js
Hi, lots of questions here...
Starting with the easy one, about skins: Jens and I both prefer the Scratch 1.4-style dark backgrounds and 2½-D blocks. We do have "Flat design" (in the settings menu) which you may like better. I hate it, but chacun à son gout. We would discourage other skins; they'd just slow down the UI without making the actual language any better.
About contributing: Thank you for offering. Jens is pretty protective of his code; please discuss anything you want to add before you start working on it. Exception: If you fix a bug from the Github bug tracker, by all means file a PR referencing the issue number. But first read the file CONTRIBUTING.md in the repo.
I'm not sure what you mean by this. We just released 6.0 which is a major rewrite, adding hyperblocks and other APL features. We are constantly improving the language.
I think the first thing you notice is the UI, and you're right that we aren't so interested in changing that. I strongly recommend that you spend some time exploring the actual language -- the blocks, both built-in and in the libraries. The core features that are unique to Snap! are first class procedures, first class lists, and first class sprites. We also added first class costumes, first class sounds, and first class continuations. Jens has also worked hard at dramatic speed improvements in handling large lists, mostly for the sake of media computation (e.g., manipulating a costume programmatically) but also for "big data" applications.
Frankly, we've had bad experiences with volunteer developers who get a project 95% done and then lose interest (because the remaining 5% is the hard part). So you should expect some skepticism about letting you contribute code. But you can overcome that if you write really clean, robust code to fix bugs. Right now there are three people from whom Jens happily accepts code, although still reviewing it carefully before pulling (not including me; my code sucks and my contribution is in language design and knowing how to say "first class") and a few more who've written large chunks of code.
The Snap! web site that allows publication of projects is still fairly recent, and is a work in progress. We do collect some statistics but have barely begun; lots of site and back end issues are much more urgent than that, especially to support teachers.