
EliasDB – A graph-based database - kawera
https://github.com/krotik/eliasdb
======
jzelinskie
Issue #1 has a pretty solid write up by the author for why not dgraph or
cayley[0]. In this post the author also mentions it's a rewrite from Java
(which is quite obvious if you look at the code). I hope the project becomes
more idiomatic Go as the author learns the language. In scenarios like this
where a project for the author's learning and not necessarily production use,
I wish GitHub had a better way to distinguish this from stable software
looking for adoption.

[0]:
[https://github.com/krotik/eliasdb/issues/1#issuecomment-2494...](https://github.com/krotik/eliasdb/issues/1#issuecomment-249425914)

~~~
pavlov
Then again, Linux started with a newsgroup post that read:

 _" I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones."_

If there was a "student ghetto" for open source, it might even be more harmful
in net: overly humble creators would feel their good projects belong there,
while the self-promotional extroverts would focus on getting their crap among
the "real projects" just for personal fame.

~~~
derefr
I think the distinction isn't so much between "student/hobby projects" and
everything else, so much as it is between "projects that go through the
motions overly-formally to learn the motions, rather than to achieve the goal"
(i.e. the result of doing a code kata) and projects that are created with
intent to put them into—at least hobbyist—production. Even quickly dashed off
scripts are useful to others; while perfected, deliberate homework assignments
usually aren't.

Partitioning the search results of sites like GitHub based on such a factor
_might_ be useful.

You're right, though, that people wouldn't know well-enough at the time to
self-report this "is practically-applicable rather than an academic exercise"
property. It'd be more useful as a fact derived from social-
bookmarking/tagging of repos, I think.

GitHub already has a pretty good signal for practicality in its "stars";
people don't star things that aren't useful to _them_ in some sense. You could
maybe add some other explicit signal (maybe a "hide" button in the search
results) to serve as a negative signal.

Better yet, though, you could build some sort of "BlackBoard for CS"
education-workflow site on top of GitHub, and use _its_ positive signals (this
_is_ academic) as the negative signal for GitHub itself.

(As an aside: I've always wondered why more sites don't use this approach.
It's way easier to incentivize people to tag something they _want_ vs.
something they _don 't_. Build a second frontend for your site that serves the
user-base you _don 't_ want on your main site, and serves them _better_ —and
then have that frontend add the ghetto-tag to everything it passes to the
backend.)

