GitHub for hosting open projects or a social semantic desktop?

6 views
Skip to first unread message

Paul D. Fernhout

unread,
Aug 28, 2010, 6:02:02 PM8/28/10
to Open Manufacturing
A question at the end of this about GitHub is mostly directed mostly to
Bryan, but other should feel free to jump in, too.

===

I'm looking to put up some old source code (our garden simulator stuff,
etc), as well as do some new stuff on information management and I'm trying
to decide between:

SourceForge vs. Google Code vs. Launchpad vs. GitHub

with (as the typical version control choice on each -- not all support all):

SVN vs. Mercurial (Hg) vs. Bazaar vs. Git

This is also a general issue for open manufacturing projects too, as in, how
does everyone share your design drawings and related communications these
days? (And their certainly are a lot of possible ways to do that.)

Anyway, it's just something that can get revisited from time to time as
service offerings come and go. There are a lot of discussions on the web
about all this, and a lot of it boils down to personal preferences,
familiarity, or exact details of what one is doing, or some sort of faddish
social momentum. :-) So, I don't know if a discussion here will shed a lot
more light, but I would bring up the topic anyhow, as far as my assessment
of social momentum.

Bryan uses GitHub, for example:
http://github.com/kanzure/skdb

I've projects already on SourceForge and Google Code (mainly using SVN).
http://sourceforge.net/projects/pointrel/
http://sourceforge.net/projects/patapata/
http://code.google.com/p/openvirgle/

Can GitHub essentially just be used to support an open source project?

This says:
http://en.wikipedia.org/wiki/GitHub
"GitHub also operates a pastebin-style site, wikis for the individual
repositories and web pages that can be edited through a git repository."

And on the site: "Free public repositories, collaborator management, issue
tracking, wikis, downloads, code review, graphs and much more�"
http://github.com/

Review:
http://www.web-hosting-top.com/web-hosting/web-hosting-top.github.com-reviews
http://www.readwriteweb.com/archives/github_a_social_network_for_programmers.php

Here is my particular purpose, in the sense that it may make a difference
which approach I choose.

GitHub seems appealing because it is easy to get more free ad hoc open
repositories, which I might want to use for various communications tasks. I
could then adapt the Pointrel system I work on to work with a git backend,
sort of like Google Wave, but where you would use Git as a back end for,
say, an ongoing collaboration using desktop software (in Java) but shared
through git (or hg or svn or bazaar, if I went one of those ways instead).
The current version of the Pointrel System already supports lots of other
backends for sharing, so adding git support or other VCS support of some
form (even via shelling out to the command line or by people doing things in
git manually) could be doable without too much trouble.

That's probably all confusing to most people, but here is a hypothetical
example. Imagine you fire up a Java or other JVM-based application that
somehow handles a lot of information about open manufacturing and design
(including having stuff about materials, the periodic table, little
tutorials, an inventory of stuff on hand, a map of your local community, or
whatever), and to address some current need you write some documents in it
or work on some CAD files (maybe using other programs too from the shell,
like some CAD software or SKDB), perhaps pulling those files into and out of
the Pointrel system (where they might get tagged, annotated, further
discussed, analyzed, and so on, as part of a social semantic desktop). And
then you use git to push all that changed information to a shared repository
for a workgroup. And then other people in that workgroup pull those changes
back down and make more changes (and maybe push some of those changes to
other git repositories or other different workgroups they may be in as well,
subject to compatible licenses). Much of this might sound familiar (SKDB has
aspects of it, and I can credit Bryan and Ben with the notion of focusing on
using existing tools like git with SKDB). The big difference is that most or
all of those files would be in a format similar to RDF supporting semantic
linking of information (so, various applications could ride on top of all
that for building and using more complex metadata relating to everything).
SKDB has an aspect of this with using YAML, though perhaps not as general
(YAML is not trying to be about defining semantic links like RDF or the core
of the Pointrel system is.). One application might look a lot like something
that was a mailing list or web forum (although the communicated information
would be stored in files in the git repository); another application might
look like a structured argument wiki module; example:
http://makethecase.net/wiki/Make-the-Case_Case_Index
http://www.ai.sri.com/~seas/
http://www.ai.sri.com/~angler/
Another might support organizing stories or use cases:
http://www.rakontu.org/ (my wife's stuff)
There might end up being a lot of modules, some of which might just wrap
other stuff (even web applications).

Anyway, that still probably doesn't clear things up very much, :-) but is a
short overview of the general concept I am thinking about as a platform for
a variety of tools. Right now, I'm calling it Twirlip of the Mists. :-)
"Twirlip Wholistic Integrated Resource Linking Intelligence Platform --
Mutual/Modular Intrinsic/Intelligence Security/Sensemaking Tools"
http://www.twirlip.net/
http://pointrel.svn.sourceforge.net/viewvc/pointrel/trunk/Pointrel20090201/source/org/pointrel/pointrel20090201/applications/twirlip/
http://slashdot.org/comments.pl?sid=1746980&cid=33177866

The key point is, something like git or hg or svn or bazaar could be the
backend for such a communications infrastructure (and maybe even be mostly
invisible to the user using some Java software or whatever else). And, it's
a bit grandiose, I know, but I'm seeing this as essentially a system that
almost anyone interested in open manufacturing would want to get running on
their desktop just for all the useful tools it might provide on top of that
platform, ideally as reasonably secure sandboxed Java modules that would run
on all major platforms (mac, win, GNU/Linux). I know in practice people
would probably use lots of tools, and things fragment, but that's still what
I'm aiming at -- some platform for thinking through complex issues
(including related to manufacturing) using a variety of tools that were
somehow semantically interlinked, with something like git through GitHub as
the most common backend for small group sharing/collaboration.

I also like the thought that I could, in theory, get private repositories
for workgroups at GitHub for a fee (for example, a family or small group of
friends might want to put up some personal discussions, or for some group of
people working on some new product they might not be ready to share with the
world yet). It seems to me perhaps easier to use Git through GitHub as a
backend than Google App Engine or Amazon S3 for simple stuff related to
having some common files shared across a small workgroup. GitHub essentially
is just providing a simplified interface to the more general cloud in that
sense. If I pick Google Code or SourceForge or Bazaar (I know little about
the last), for every repository, you have to have a project, and state a
purpose and have that reviewed perhaps, and so on, which seems like a lot of
social overhead compared to just creating another git repository.

Still, GitHub could just disappear (more likely than Google Code or
Launchpad, I'd suspect), although you'd presumably have a local copy of all
the history, so it might not be that big a deal compared to an svn host
going down without backups. You'd just then need to find some new place to
host your git archives (although anything special relating to web pages or
commit hooks and such might be a problem).

And also, GitHub does not provide a direct way to have mailing lists it
seems. Although neither does Google Code (you have to use Google Groups).
But GitHub does seem to have something about post-commit hooks (like via
email or Jabber), so maybe that could be good enough for what I would like
to do or synchronizing people working together if they put most of their
content and discussions into a git repository using the Pointrel system?

SourceForge seems slow sometimes, and I can wonder if something as
specialized as GitHub might be faster and more reliable if it just tries to
do a few things well. And to do much with Google Code, you have to be
constantly logged into Google, which means Google knows more about other
things you do at the same time (unless you have a fancy setup).

Any thoughts? Bryan, have you been happy with GitHub? Is it reasonably well
performing in terms of reliability and speed? Have you tried their web
related tools, wikis, email commit hooks, etc. yet? Are you still liking git
(compared to other DVC options)?

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.

Atrus

unread,
Aug 28, 2010, 8:51:45 PM8/28/10
to openmanu...@googlegroups.com

Codewise, hg and git have better merging capabilities thann SVN or CVS.

On Aug 28, 2010 6:02 PM, "Paul D. Fernhout" <pdfer...@kurtz-fernhout.com> wrote:

A question at the end of this about GitHub is mostly directed mostly to Bryan, but other should feel free to jump in, too.

===

I'm looking to put up some old source code (our garden simulator stuff, etc), as well as do some new stuff on information management and I'm trying to decide between:

 SourceForge vs. Google Code vs. Launchpad vs. GitHub

with (as the typical version control choice on each -- not all support all):

 SVN vs. Mercurial (Hg) vs. Bazaar vs. Git

This is also a general issue for open manufacturing projects too, as in, how does everyone share your design drawings and related communications these days? (And their certainly are a lot of possible ways to do that.)

Anyway, it's just something that can get revisited from time to time as service offerings come and go. There are a lot of discussions on the web about all this, and a lot of it boils down to personal preferences, familiarity, or exact details of what one is doing, or some sort of faddish social momentum. :-) So, I don't know if a discussion here will shed a lot more light, but I would bring up the topic anyhow, as far as my assessment of social momentum.

Bryan uses GitHub, for example:
 http://github.com/kanzure/skdb

I've projects already on SourceForge and Google Code (mainly using SVN).
 http://sourceforge.net/projects/pointrel/
 http://sourceforge.net/projects/patapata/
 http://code.google.com/p/openvirgle/

Can GitHub essentially just be used to support an open source project?

This says:
 http://en.wikipedia.org/wiki/GitHub
"GitHub also operates a pastebin-style site, wikis for the individual repositories and web pages that can be edited through a git repository."

And on the site: "Free public repositories, collaborator management, issue tracking, wikis, downloads, code review, graphs and much more…"


--
You received this message because you are subscribed to the Google Groups "Open Manufacturing" group.
To post to this group, send email to openmanu...@googlegroups.com.
To unsubscribe from this group, send email to openmanufactur...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openmanufacturing?hl=en.

Paul D. Fernhout

unread,
Aug 29, 2010, 10:20:41 AM8/29/10
to openmanu...@googlegroups.com
Atrus wrote:

> On Aug 28, 2010 6:02 PM, "Paul D. Fernhout" wrote:
>> A question at the end of this about GitHub is mostly directed mostly to
>> Bryan, but other should feel free to jump in, too.
>
> Codewise, hg and git have better merging capabilities thann SVN or CVS.

Thanks, I agree on that.

And if I went with, say, Google Code for another project, I'd use hg at this
point. Likewise, I'd pick git or hg at Sourceforge.

I created a "free" GitHub account and repository just to play around with it.
http://github.com/pdfernhout/Twirlip_Test001

I've also been learning a little more about how GitHub publishes static web
sites.
http://pages.github.com/

Here is an example page hosted at GitHub using a domain:
http://tom.preston-werner.com/2009/05/19/the-git-parable.html

Although that's not a big issue for me I realize, as I could just copy
content to my own site. I can see how it is convenient though to not have to
copy stuff to another site and probably run a tool on it to transform
content. I can wonder about presumably not having access logs probably
though (useful to get a sense of how much a page is accessed or by what part
of the world or through what search terms). It is nice you can redirect a
domain to GitHub pages though.

Also, SourceForge or Google Code are clear about licenses when you make a
project, but GitHub has no way to have that organized systematically that
I'm aware of.

Still, it is a very different social model of people building on each others
code at GitHub, one I am still trying to get a feel for. I can wonder how
that distributed model might translate to work on designing complex
mechanisms other than software?

Paul D. Fernhout

unread,
Aug 30, 2010, 1:03:35 PM8/30/10
to openmanu...@googlegroups.com
Paul D. Fernhout wrote:
> Atrus wrote:
> > On Aug 28, 2010 6:02 PM, "Paul D. Fernhout" wrote:
> >> A question at the end of this about GitHub is mostly directed mostly to
> >> Bryan, but other should feel free to jump in, too.
> >
>> Codewise, hg and git have better merging capabilities thann SVN or CVS.
>
> Thanks, I agree on that.

Just as a follow up, this Python PEP gives a good explanation of the
advantages of a distributed version control system (and why python decided
to go with Mercurial over Bazaar or Git):
http://www.python.org/dev/peps/pep-0374/

Mentioned in a comment here:
http://code.google.com/p/support/wiki/DVCSAnalysis

Google Code supports Mercurial (not Git). BitBucket pretty much does the
same as GitHub as far as the basics (1 GB free space and one private
repository, and you can pay for more space and for more private repositories):
https://bitbucket.org/plans

Given that I'm now leaning to Google Code, I'm starting to lean to
Mercurial. The fact that Mercurial is implemented in Python (instead of C)
is a plus in terms of maybe integrating a Jython version of it at some point
directly in a Java application (although there were issues with that):
http://fwierzbicki.blogspot.com/2009/02/progress-with-mercurial-on-jython-part.html

Anyway, any more comments by active users would be appreciated.

I think at this point I'm probably going to go anyway with Google Code for
hosting the old code projects but with a Mercurial repository.

I noticed something funny though that makes me still think about putting the
projects on SourceForge anyway, despite complexity and slowness: :-)
http://sourceforge.net/users/paulfernhout
"# Joined: 2000-01-06 (11 years ago) # User ID: 4894"

That's a pretty low number out of 2,000,000+ developers now. :-)

But my wife likes Google Code (where she has a project) better than
SourceForge (where she also had put the project but found it too complex and
unstable and moved it to Google Code). For example she started using the
Wiki stuff as SF there just as SourceForge was breaking it. So, I can't
blame her. Google Code is much easier and more stable it seems to use for
the basics, at least for a small project that does not want a lot of other
fancy stuff that SourceForge offers or has offered (cgi scripts, MediaWiki,
etc.). And while Google Code does end up having you lose privacy by being
logged into Google, in practice, we're probably logged in or trackable
anyway most of the time. And with using Mercurial, other people can just
download the code and do what they want to do away from a Google site.

There are several things I like better about git (like having full copies of
files rather than deltas). If Google Code supported git, I'd probably
leaning more towards it and git. I do thing git may be winning the developer
mindshare thing with the support from everyone developing the Linux kernel
and so on. But either seems OK-ish.
http://www.wikivs.com/wiki/Git_vs_Mercurial
"Mercurial is claimed to be simpler and easier to learn than Git. However,
Git is more flexible and powerful. Git provides more lower-level commands
than Mercurial, allowing virtually direct access into the inner workings of
the repository. Even so, many of the same things are achievable with both. "

One thing I did not like from my experiment with GitHub was having the
repositories have a URL under my own id, as in github.com/userid/reponame.
I like the idea of the project being its own thing, especially if you want
to get others involved in it. It's a minor seeming thing, and probably
solvable with having an account for each project (although GitHub say you
can only have one free account), or maybe some other way. But with the
license defined for a project at Google Code as well, I'm leaning that way
right now rather than host a project at either GitHub or BitBucket (which
presumably has the same issue?)

And then I can just move to Mercurial for support for collaboration, and use
BitBucket if I want that kind of hosting (people in the past have said
BitBucket basically just copied the GitHub idea). I don't feel as good about
BitBucket as GitHub because it is smaller, but at least the facility is there.

And likely I'll end up supporting git and GitHub at some point too; in any
case, there is some degree to which these things can interoperate.

Is there anyone here who regularly uses both git and hg? Or who can say how
easy it is to interoperate?

Anyway, just some current thoughts. I'm still a little paused on using
Google for so much. But I'm kind of stuck with it for moderating this list
or other things anyway... So, I might as well get something out of it.

It's not easy to make these decisions...

I used to use darcs for a while several years ago. :-) But ended up just
using mostly svn. And darcs seems to be falling by the wayside... As so many
small projects do once they prove a concept or innovate in some area as part
of a bigger trend. (The Pointrel system may well end up the same way, and
certainly seems eclipsed by RDF and Metaweb and whatever.)

Marc Juul

unread,
Aug 30, 2010, 10:55:20 PM8/30/10
to openmanu...@googlegroups.com
On Mon, Aug 30, 2010 at 7:03 PM, Paul D. Fernhout <pdfer...@kurtz-fernhout.com> wrote:
One thing I did not like from my experiment with GitHub was having the repositories have a URL under my own id, as in github.com/userid/reponame.

GitHub also lets you set up accounts for organizations, so you could have github.com/projectname/reponame

--
Marc

Paul D. Fernhout

unread,
Aug 31, 2010, 12:56:40 AM8/31/10
to openmanu...@googlegroups.com

I see that now, good point, thanks.
http://github.com/blog/674-introducing-organizations

I see you can have a free one for open source, too.
https://github.com/account/organizations/new

Not sure if it needs a different email though.

Been messing around with Mercurial and enjoying it so far (just playing
around with the Eclipse plugin and the command line stuff, and also
converting an svn repository as a test).

While I haven't signed up for an account on bitbucket yet (can't decide
whether to have a personal or organizational name if I have to choose just
one for a free account), I've noticed that bitbucket.org seemed pretty
slower to handle web page requests than github earlier today (but seems to
be working better now, but still slower). Hard to know if that is a quirk
from limited testing. Also, I haven't pushed or pulled stuff there, so I
don't know if the repositories are also a little slower to use directly.

I'm not sure if bitbucket does organizations though (at least, not for free
-- you could create a paid account for that, obviously). They don't mention
them here (where they talk about Access Control Lists), so I doubt they have
them yet:
https://bitbucket.org/help/Collaborating

But using hg, git, or bzr as a backend for storing Pointrel files (that
could have shared manufacturing data) is definitely growing on me as a
concept. (Rather than have a special server...) I like that idea that one
could have a tool and tell people, sign up here for free hosting if you
want, and then point the tool at a url (and maybe put in a password and user
id) and start collaborating.

Bryan Bishop

unread,
Sep 1, 2010, 10:48:40 AM9/1/10
to openmanu...@googlegroups.com, Bryan Bishop
On Sat, Aug 28, 2010 at 5:02 PM, Paul D. Fernhout wrote:
> A question at the end of this about GitHub is mostly directed mostly to
> Bryan, but other should feel free to jump in, too.

Hi paul, thank you for the discussion. I have been heads down writing a visualization front-end. I am sure you remember, but we chatted privately a while back about a STEP parser (or at least file-format-thingy generator); so I've written that, and am now making a visualizer and cleaning it up before I release it / demo it (and no I will not release it until it at least works). But I figure I need a welcomed distraction for now.


> I'm looking to put up some old source code (our garden simulator stuff,
> etc), as well as do some new stuff on information management and I'm trying
> to decide between:
>
>  SourceForge vs. Google Code vs. Launchpad vs. GitHub

Some OSS projects host their code in multiple places; for instance, I've seen some projects that have both a freshmeat and a sourceforge account. It's also not uncommon for old mammoth projects to be hosted in svn (after upgrading from cvs) and also have a bi-directional gateway to some distributed revision control system (like git) because the cats get angry. I have no objection to this sort of practice, but there are some technical caveats, like svn-to-git-back-to-svn conversion issues.


> with (as the typical version control choice on each -- not all support all):
>
>  SVN vs. Mercurial (Hg) vs. Bazaar vs. Git

Funny that you don't say "CVS vs. SVN vs.. "; I think it's pretty clear that people should be using svn, not cvs. As for the distributed revision control systems, I am very biased towards git (solely as a matter of experience) but have used mercurial and bazaar and can't really complain. Some people say that mercurial and bazaar are easier to learn on, and it might be true, but I wouldn't know because I started my distributed control journies with git.


> This is also a general issue for open manufacturing projects too, as in, how
> does everyone share your design drawings and related communications these
> days? (And their certainly are a lot of possible ways to do that.)

I guess you're asking two things:

(1) how are contributors, who for some reason produce a design or schematic, licensing it and then putting the files up on the internet? Well, frankly, thingiverse and other filebins. They upload a few files, slap on a license. This is of course needed and a useful community service, but there's no development, no revision control; this ain't no typical software development workflow.

(2) how do people who understand workflows and open source manufacturing contribute open source hardware to the web at large? In SKDB, hardware packages are actually git repositories for each component (more or less).


> Anyway, it's just something that can get revisited from time to time as
> service offerings come and go. There are a lot of discussions on the web
> about all this, and a lot of it boils down to personal preferences,
> familiarity, or exact details of what one is doing, or some sort of faddish
> social momentum. :-) So, I don't know if a discussion here will shed a lot
> more light, but I would bring up the topic anyhow, as far as my assessment
> of social momentum.

There is definitely social momentum in various directions that are either (1) missing this open source hardware/manufacturing community, (2) doing various things on their own, etc. For instance, thingiverse has continuously refused to any sort of standardized data format. On that note, they are currently looking to hire a web developer, and while I am qualified for the position I am also hoping others from this community have applied. Another instance of social momentum is the reprap project, and how Sebastien had to force all of the reprap users to their latest wiki installation, and has now reservations about moving to any sort of open hardware standard because his cats will get angry and leave? or something.


> Bryan uses GitHub, for example:
>  http://github.com/kanzure/skdb

Meh, think of that just as a mirror.


> I've projects already on SourceForge and Google Code (mainly using SVN).
>  http://sourceforge.net/projects/pointrel/
>  http://sourceforge.net/projects/patapata/
>  http://code.google.com/p/openvirgle/

FTR, I've used sourceforge as well. I haven't bothered to throw up any project on Google Code yet.


> Can GitHub essentially just be used to support an open source project?

Uh, sure, throw up a repository.


> This says:
>  http://en.wikipedia.org/wiki/GitHub
> "GitHub also operates a pastebin-style site, wikis for the individual
> repositories and web pages that can be edited through a git repository."

I often find a lot of that other stuff extraneous. For bug ticketing, I've become fond of Bugs Everywhere, which keeps the bug ticketing system under revision control in the repository itself, so you take it with you. It's compatible with git, bzr, hg, etc. For wikis, I am fond of ikiwiki and other similar wikis, which use the repository for revision control. GitHub does this to some extent with their markdown rendering of readme files et al.


> And on the site: "Free public repositories, collaborator management, issue
> tracking, wikis, downloads, code review, graphs and much more…"
>  http://github.com/

Their graphs are definitely fun to look at though :-)
http://github.com/kanzure/skdb/graphs/punch_cardYou should also look into gitorious if you're interested in GitHub.


> GitHub seems appealing because it is easy to get more free ad hoc open
> repositories, which I might want to use for various communications tasks. I
> could then adapt the Pointrel system I work on to work with a git backend,
> sort of like Google Wave, but where you would use Git as a back end for,
> say, an ongoing collaboration using desktop software (in Java) but shared

I am not sure what revision control system the Google Wave protocol uses. I know that they use the XMPP/Jabber protocol in general, but IIRC I seem to recall that the Wave guys did their own revision control system? I hope I am wrong.


> I also like the thought that I could, in theory, get private repositories
> for workgroups at GitHub for a fee (for example, a family or small group of
> friends might want to put up some personal discussions, or for some group of

There's also the ikiwiki hosting service:
http://branchable.com/
which does the same for private repositories.


> sense. If I pick Google Code or SourceForge or Bazaar (I know little about
> the last), for every repository, you have to have a project, and state a
> purpose and have that reviewed perhaps, and so on, which seems like a lot of
> social overhead compared to just creating another git repository.

Bazaar is like git, so it doesn't really belong in "Google Code vs. SourceForge".


> But GitHub does seem to have something about post-commit hooks (like via
> email or Jabber), so maybe that could be good enough for what I would like
> to do or synchronizing people working together if they put most of their
> content and discussions into a git repository using the Pointrel system?

You could also just use git post-commit hooks without GitHub. When I push revisions to the git repository for SKDB on GitHub, a bot sends a message to #hplusroadmap. Actually, I think someone configured the git repository on designfiles.org to do that now, so that hook was deleted from the github account.


> Any thoughts? Bryan, have you been happy with GitHub? Is it reasonably well
> performing in terms of reliability and speed? Have you tried their web
> related tools, wikis, email commit hooks, etc. yet? Are you still liking git
> (compared to other DVC options)?

I just use GitHub as yet-another-mirror, so it's not really a critical point in my personal infrastructure. I gave their commit hooks a few tries- tweets, email, IRC, whatever. I played around with markdown a bit but didn't care enough. I don't have a strong opinion yet on git vs. bzr vs. hg for new projects.

- Bryan
http://heybryan.org/
1 512 203 0507

Paul D. Fernhout

unread,
Sep 1, 2010, 12:37:49 PM9/1/10
to openmanu...@googlegroups.com
Bryan Bishop wrote:
> On Sat, Aug 28, 2010 at 5:02 PM, Paul D. Fernhout wrote:
>> A question at the end of this about GitHub is mostly directed mostly to
>> Bryan, but other should feel free to jump in, too.
>
> Hi paul, thank you for the discussion. I have been heads down writing a
> visualization front-end. I am sure you remember, but we chatted privately a
> while back about a STEP parser (or at least file-format-thingy generator);
> so I've written that, and am now making a visualizer and cleaning it up
> before I release it / demo it (and no I will not release it until it at
> least works). But I figure I need a welcomed distraction for now.

Sounds neat.

Thanks for all the comments.

Bugs Everywhere sounds neat. :-) And it's a bit like what SKDB or now the
Pointrel system (following your lead) is working towards -- using a version
controlled shared DVCS file system as a communications medium.

> I just use GitHub as yet-another-mirror, so it's not really a critical point
> in my personal infrastructure. I gave their commit hooks a few tries-
> tweets, email, IRC, whatever. I played around with markdown a bit but didn't
> care enough.

I see. You make a really good point indirectly on how the flexibility of
using DVCS opens a lot of options... So, some of these decisions are not so
crucial as they might have been in the past. It would still be a pain for
people to update URL links perhaps, but it is not like everything is lost
if, say, GitHub disappears. The community would have to regroup elsewhere,
but the information would still (mostly) be there, in a sort of holographic way.

I'm looking some at gitorious right now, too, as you mentioned.

> I don't have a strong opinion yet on git vs. bzr vs. hg for new
> projects.

At the moment, from what you said, and what Marc said on organizations, and
some other issues, I'm leaning back to git at the moment.

Having looked, it really seems like the social momentum is in GitHub's favor
(it is maybe 10X the size of BitBucket). And git seems to have improved a
lot in terms of useability from what people say (so the hg advantage is not
as big as it once was).

The idea of editing the files directly on GitHub also has some appeal to me,
from a blogging perspective, and just in general, being able to work from
different locations on something through a web browser. Otherwise, I've
sometimes made changes on our sites by hand at the site, and then had to
remember to copy them into our SVN repository. It would be nice to be able
to just do a "pull" instead. But I don't see that being a huge thing, even
though it is nice.

For me, a big thing potentially is JGit, which reimplements the core of git
as a standalone Java package, which would make it easy for me to use git
servers from Java. See:
http://www.jgit.org/
"JGit and EGit are implementations of the Git SCM (by King Penguin) in Java."

Mercurial does not seem to have quite the same thing even though Mercurial
is almost entirely in Python. There are a few C dependencies, and Jython
can't handle those. It's not that it could not be done, it's just that it
hasn't been done. So, where do I want to spend my time if I don't especially
care which one I focus on at first? (Ultimately, I might want to support any
backend for sharing content, but it is nice to have one at first that works
easily, like git.)

You can find the same thing in Python for git, by the way, which might be
useful for SKDB if you want a standalone version (but there is nothing wrong
with the command line use the command line if you are willing to accept that
people have to install git seperately, which is not a big deal for Debian,
although more problematical on Windows or the Mac):
https://launchpad.net/dulwich
"Dulwich is a pure-Python implementation of the Git file formats and protocols.

For what I'm thinking about, I can imagine you can, say, launch a Java
webstart application (say, from a webpage on GitHub), and that application
has many GUI tools in it (like "Bugs Everywhere" in concept), and that
application can then use JGit to talk back to GitHub directly to post
changes or retrieve new changes others have made to common repositories. Or
something like that... It could also use other intermediate systems instead
of GitHub (Gitorious, SourceForge, shared directories, whatever).

So, that all leans me back to focusing more on git. If two things are about
the same, then the social momentum seems like a big win. But it is more than
that, because the social momentum has lead to it having one key library to
support something that I want to do (use it from Java easily), then that is
an important issue. If hg was a lot better technically, that might not
matter. But it seems, if anything, git can do a bit more (why it has been
seen as harder to use), although it is true that hg may have advantages as
well (like a better understanding of copies and moves?).

Also, the performance of the GitHub site at the moment seems better than
BitBucket (although Google Code may be faster for hg projects). Those things
can change, but it is just one more datapoint. Still, in BitBuckets favor,
anyone can get one private project, so for that reason alone, support an hg
backend down the road might be worthwhile (like for a team that for whatever
reason want's a free private space for a time). But, you can still pay for
privacy at GitHub (the new business model of our open times? :-), so that is
not an overwhelming advantage. And in any case, with git, you can still
share data privately in other ways. The current design of the Pointrel
System has a variety of backends already some of which could be private
(archives right now can be any of cgi, directory, ftp, (read only) http,
preferences, sftp, in RAM, or a (read only) zipped directory):
http://pointrel.svn.sourceforge.net/viewvc/pointrel/trunk/Pointrel20090201/source/org/pointrel/pointrel20090201/core/
But focusing on something like git might just be easier to explain. :-)
Actually, in some ways, now I wish I had just used git as a backend from the
start, rather than implement all those other ones like ftp or cgi for
exchanging resource files.

Anyway, I'm kind of sold that git and GitHub (and gitorious, etc.) are a
good way to go for doing projects involving revision control and sharing,
something you decided quite a bit earlier. :-) And for my long term needs,
git makes a better overall choice right now.

I'm still not sure what I'll pick for the various projects though as far as
hosting though, especially if I focus more on git and Google Code only
supports hg. I could perhaps use svn on Google Code and then just use
git-svn or something as an interface. Or I could go with SourceForge and
git. Or I could just host those projects on GitHub, but to have their own
URLs I have to create an organization for each project? And maybe pay for
that? I have to think about the social aspects of what I am doing with
trying to present those projects (as well as what my wife likes, since she
did a lot of work on those project too and might still want to do stuff with
them). I guess it's not a huge choice in the sense that things can get
interconverted. But that's just all wheel spinning in a way; I'd rather get
closer to something at the start which I don't have to think about much later.

Right now, I've been experimenting with converting parts of our big local
svn repository to a DVCS to try to preserve history but also remove some
things that may be checked in that we don't want to redistribute for
whatever reason. Mercurial was able to do it fairly OK; git has taken
several times longer (but at least it finally is a program that would use
all the eight cores on my desktop for a bit. :-) Also, I still need to
figure out more about how git can split one big SVN repository into multiple
projects. There is stuff out there to help, but it takes a while to
understand and adapt; examples:
http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
http://blog.woobling.org/2009/06/git-svn-abandon.html
I think the git conversion will ultimately be cleaner though than the hg one
because git supports tags better it seems? And that may be part of why it is
taking longer? Anyway, a lot to learn and sort out.

Thanks again for your comments.

Bryan Bishop

unread,
Sep 1, 2010, 1:03:55 PM9/1/10
to openmanu...@googlegroups.com, Bryan Bishop
On Wed, Sep 1, 2010 at 11:37 AM, Paul D. Fernhout wrote:
You can find the same thing in Python for git, by the way, which might be useful for SKDB if you want a standalone version (but there is nothing wrong with the command line use the command line if you are willing to accept that people have to install git seperately, which is not a big deal for Debian, although more problematical on Windows or the Mac):
 https://launchpad.net/dulwich
"Dulwich is a pure-Python implementation of the Git file formats and protocols.

Yep, that's what I was using for a while when I was writing a python web app to be a wiki front-end for git repositories. However, it turns out that dulwich and the other python/git options aren't quite robust yet. The ruby/git world is apparently much stronger. Oh well. Some of that is changing lately.

Paul D. Fernhout

unread,
Sep 3, 2010, 12:43:42 AM9/3/10
to openmanu...@googlegroups.com
Just another item that reminds me about how every Squeak Smalltalk image was
essentially a fork: :-)
http://adam.heroku.com/past/2009/1/20/github_vs_sourceforge/
"Alan Gutierrez compares Sourceforge and Github. In short: Sourceforge is
for projects, while Github is a place to put your code. It doesn�t have to
be a full project. It doesn�t have to work. It�s just a way to share your
code with other hackers who might be interested. And they can fork it and
start collaborating.
The culture of traditional open source software projects (like the
Apache, MySQL, Subversion, or Gnome) treats forks as a negative and
disruptive force. When XFree86 was forked into Xorg, for example, there was
much drama in the community. Or note Josh Matthews� hand-wringing over free
software's hidden burden.
With Git (and other decentralized revision control systems), forking is a
normal and healthy activity, and a part of your everyday workflow. Fork and
merge all over the place! Unfettered experimentation! This is next step in
the evolution of open source.
"""

I seem to be leaning now to choosing between SourceForge/Git and GitHub for
some old projects to put online (after having read a lot more about bzr and
its neat features today, and bzr also has Java support, but then being back
to persuaded by social momentum towards git, even with its flaws. :-)
http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/
http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/

I can see the social value aspects of GitHub for community development.

But I can also see the value of having a project page like at SourceForge,
and it seems otherwise I need to create a GitHub "organization" for each
project to get a url that starts with a project name and where there can be
a web page about the project associated with that?

Assuming I can do that, as it wants another email it seems? Not sure it will
let me reuse the one I created the free personal account with as I have not
tried making one yet.

Anyway, I'm still caught between two paradigms, I guess. :-)

But in any case, this does suggest that open manufacturing design may
sometimes go the same way -- people moving from a project mindset (say, a
super chair) to a fork and merge mindset (say, lots of customized chairs
with people sharing tweeked designs back and forth).

Paul D. Fernhout

unread,
Sep 3, 2010, 1:04:06 AM9/3/10
to openmanu...@googlegroups.com
Paul D. Fernhout wrote:
> Just another item that reminds me about how every Squeak Smalltalk image
> was essentially a fork: :-)
> http://adam.heroku.com/past/2009/1/20/github_vs_sourceforge/
> "Alan Gutierrez compares Sourceforge and Github. In short: Sourceforge
> is for projects, while Github is a place to put your code.["]

Another item about that, including the project point I raise:
"GitHub and Git: Sharing Your Code, for What It�s Worth, Without a Begging
Entry into Open Source Communities"
http://kiloblog.com/post/sharing-code-for-what-its-worth/
"Naming a project is simple. I can give my project a name of my choosing. It
is not a tedious affair akin to choosing a domain name, a dozen little stabs
of disappointment, to land upon some hyphenated moniker. ..."

I guess it is in that sense a different notion of "project" as a more
virtual sort of thing...

And a comment there:
"Giles Bowkett, on November 16th, 2008 at 1:40 pm Said:
This is what makes it awesome. Likewise with forking other people�s
projects. You don�t have to give a shit what they think about what you�re
doing. You do what you do, they do what they do. If you get along, fine,
that�s great, but people who want to bully you because they control the repo
(oooh) will never get any leverage out of Git."

Though I'm then immediately thinking Manuel DeLanda on all real systems
having elements of both meshworks and hierarchies,
http://www.t0.or.at/delanda/meshwork.htm
wondering, well even if that is all true, and good as far as it goes, maybe
communities tend to coalesce around feeds (mailing lists, forums, rss feeds,
specific repositories, etc.)?

And one way we do that right now, to "bless" a feed, is for someone who
cares about the project a lot (usually the original author or authors) to
have a web page about project that pops up in Google when you type in the
project name (with a better rank if the url has the name in it), and that
page then has pointers to the feeds...

On the other hand, if Google popped up the most active feeds related to the
term, then the system would be somewhat self-organizing as far as drawing
your attention to the most active areas. Of course, then would you want the
most active feed or the most stable feed? So, you might want to narrow your
search on that somehow...

From a manufacturing point of view, consider if you are Googling to find
chair designs, do you want the classics (Eames?) or the current innovators?
Example:
"New Chairs: Innovations in Design, Technology, and Materials" by Mel Byars
http://www.amazon.com/New-Chairs-Innovations-Technology-Materials/dp/0811853640

And even within classics, like say you do want to apt-get an Eames chair
using SKDB, :-)
http://en.wikipedia.org/wiki/Charles_and_Ray_Eames
do you want the old reliable and stable designs Eames Chair designs
compatible with RepRap 5 with its limited tolerances, or do you want the
cutting edge new designs being tweeked by a few artisans at the quantum
level for the alpha version of RepRap 27 for a more "authentic" feel? :-)

Paul D. Fernhout

unread,
Sep 3, 2010, 1:56:46 PM9/3/10
to openmanu...@googlegroups.com
Paul D. Fernhout wrote:
> Another item about that, including the project point I raise:
> "GitHub and Git: Sharing Your Code, for What It�s Worth, Without a
> Begging Entry into Open Source Communities"
> http://kiloblog.com/post/sharing-code-for-what-its-worth/
> "Naming a project is simple. I can give my project a name of my
> choosing. It is not a tedious affair akin to choosing a domain name, a
> dozen little stabs of disappointment, to land upon some hyphenated
> moniker. ..."

Just another use possibility, for those who already have a static website on
some server somewhere (like we do):
"Sharing a public Git repo over HTTP [flow chart]"
http://weblog.masukomi.org/2008/03/11/sharing-a-public-git-repo-over-http-flow-chart

Essentially you create a git repository on your webserver where others can
access it. Then you configure your local git repository to talk to that
repository via ssh.

Now, you're probably not going to be giving others access to ssh on your
server, but the way git works, you can pull patches from others public
sites, or people can email you stuff.

So, basically, if you already host someplace with ssh, you don't need GitHub
to put up a public git site that only you update. That adhoc approach might
be especially tempting if you had a big repository and you were already
paying for server disk space you were not using.

Using git-ftp is perhaps another option, if you have a shared host you are
already paying for but you want people to be able to both push and pull:
http://wiki.github.com/ezyang/git-ftp/

For example, the hosting provider and plan we use (pair networks) lets us
create up to 30 ftp accounts, and to restrict them to a specific directory.
Of course, FTP sends your password in the clear, so this is not a great
solution from a security perspective.

So, anyone may still prefer to use GitHub for the social aspects, or the
convenience, or the web interface to git repositories, or its easy support
for using ssh keys and related security issues, of course. I'm just
outlining another alternative, given that many people out there may already
have access to other servers with lots of disk space paid for but not used.

Also, presumably, to create unlimited private repositories, likewise, if you
put the git repository somewhere not under your public web server. And
anyone who has ssh access to your website can update it or download it.
If you have complete control over a server, you can just create accounts for
people (even sshfs-only accounts?) and grant those users read or read/write
access to various git repositories in the file system with the usual Unix-y
tools.

Again though, a place like GitHub, with the model of organizations and
adding other people with access to only specific repositories may be more
convenient. And for people on shared hosting, you probably can not set up
new accounts on the same machine for free.

I've just been thinking, well, why do I want to pay US$50 a month or
whatever to GitHub when I am already paying the same for a webserver account
somewhere else?

BTW, I think I'll be consolidating one webserver account that hosts
OpenVirgle.net, OSCOMAK.net, and openmanufacturing.net with another account.
That would save some money ($50 a month or so) now that I don't really need
a second server just to run MediaWiki or WordPress for another site (since
I'm abandoning those dynamic-cgi-webserver-oriented approaches to
information sharing in favor of static pages and a social semantic desktop
approach. Related resources:
http://www.mediawiki.org/wiki/Extension:DumpHTML
http://barnesc.blogspot.com/2005/10/mw2html-export-mediawiki-to-static.html
http://www.suodatin.com/fathom/How-to-retire-a-wordpress-blog-%28make-wordpress-a-static-site%29

So if anyone notices any hiccups with openmanufacturing.net in the near
future, that might be it. :-)

I'm still not sure how I'll do that though, because now I have to decide
between moving those sites to my other account vs. say redirecting one or
more of them just directly to any of Google Code, Google Groups, Google
Sites, or even redirecting them to a GitHub hosted website that is a
"organization". I can see that there could be a benefit to the GitHub
approach. But I'm still not clear on all the organization issues with it (I
have not made one yet).
http://support.github.com/discussions/accounts/763-github-organizations-github-pages-cnames-and-paid-accounts

But I can see the value in that GitHub approach, in then one could have
several people who could update a website (not that openmanufacturing.net is
especially essential to anything, and there are several others, like the
.org which has a lot more on it). OpenVirgle.net I like for historical
reasons. :-)

I do realize one pitfall with sharing a git repository in that if someone
else checks in something very problematical for some reason (example,
someone unthinkingly checks in information about advanced rocketry
technology deemed munitions in the USA and non-exportable, which creates a
legal problem), while you can hide such data or make it hard to access
easily, there is no way to expunge it completely without basically deleting
the entire repository and then putting it back from a local copy. So, having
a shared public repository creates its own set of risks and management
difficulties in that sense, ones that go beyond someone just deleting one
file that got accidentally checked in. From:
http://help.github.com/removing-sensitive-data/
"Be warned that force-pushing does not erase commits on the remote repo, it
simply introduces new ones and moves the branch pointer to point to them. If
you are worried about users accessing the bad commits directly via SHA1, you
will have to delete the repo and recreate it."

But of course, life is full of risks, including doing nothing and getting
overwhelmed by other trends. :-)

Paul D. Fernhout

unread,
Sep 3, 2010, 2:38:38 PM9/3/10
to openmanu...@googlegroups.com
Paul D. Fernhout wrote:
> I'm still not sure how I'll do that though, because now I have to decide
> between moving those sites to my other account vs. say redirecting one
> or more of them just directly to any of Google Code, Google Groups,
> Google Sites, or even redirecting them to a GitHub hosted website that
> is a "organization". I can see that there could be a benefit to the
> GitHub approach. But I'm still not clear on all the organization issues
> with it (I have not made one yet).
> http://support.github.com/discussions/accounts/763-github-organizations-github-pages-cnames-and-paid-accounts
>
> But I can see the value in that GitHub approach, in then one could have
> several people who could update a website (not that
> openmanufacturing.net is especially essential to anything, and there are
> several others, like the .org which has a lot more on it).
> OpenVirgle.net I like for historical reasons. :-)

Here is a related example, of a GitHub hosted site that, as near as I can
tell, uses JavaScript and jQuery (with the GitHub API) to pull in a list of
git repositories at GitHub and related information:
http://tekkub.net/
http://github.com/tekkub
http://github.com/tekkub/tekkub.github.com
http://github.com/tekkub/tekkub.github.com/blob/master/index.textile
http://github.com/tekkub/tekkub.github.com/blob/master/js/main.js

One could imagine much the same could be used to serve a page with a list of
open manufacturing designs. Each design could be stored in its own git
repository, or maybe sometimes more than one in one repository?. Then, you
might be able to then use that data with, say, SKDB to print via RepRap,
perhaps by cutting and pasting a URL into some application which cloned the
design repository or pulled a branch from it?

So, the fact that GitHub only serves static pages does not mean those pages
might not essentially be dynamic somehow (especially as they can call either
GitHub's APIs or access other information somehow...) even without the
possibility of calling cgi scripts on that host (though, such pages could
presumably call cgi scripts on other hosts, too).

I found this post also of related conceptual interest:
http://bleachbit.sourceforge.net/news/sourceforge-vs-google-app-engine-hosting
"Conclusion: Why pick one system when you can pick the best of breed?
BleachBit has chosen SourceForge for web hosting, file hosting, and SVN
hosting, while Launchpad manages bugs and translations. Google App Engine
still exists for polling Drupal on SourceForge and then delivering mail
through Google (using HTTP Mail). It's a hodgepodge, but so are the
Internet, Linux, and open source software."

Paul D. Fernhout

unread,
Sep 3, 2010, 3:07:54 PM9/3/10
to openmanu...@googlegroups.com

Just one other git-related option:
"Using jgit to Publish on Amazon S3"
http://blog.spearce.org/2008/07/using-jgit-to-publish-on-amazon-s3.html
"Recent versions of jgit, the 100% pure Java implementation of the Git
version control system, support fetch and push directly over Amazon S3. It
behaves like http push does in C git in that it is transparent to the
end-user. Transparent client-side encryption can also be enabled, in case
the repository data must be protected from the operators of S3."

I found that mentioned in a cost-related comment by someone, saying that
rather than pay a lot of money to host almost 2GB of data at GitHub (a
private code repository), they were using jGit and Amazon S3 for something
less than a US dollar ($0.30) a month.
http://calculator.s3.amazonaws.com/calc5.html
I used that calculator, and even when I add 2GB in and out each month, the
cost is still only US$0.45 a month. That's as in less than half a dollar.

So, as I said elsewhere in this thread, one can really see GitHub or
BitBucket or whatever as a convenient interface to other cloud computing,
although I had not realized how much more you are paying than Amazon S3
would cost. In the case of GitHub, where it currently costs US$22 a month to
host 2.4 GB on the Medium plan (the disk space as a "soft" limit they say,
where they will provide more if asked), it then seems what you are paying
money for is essentially some combination of convenience, commit hooks, and
being part of a dynamic social network. :-) And the free service gets you
started with that... But you can get about 100GB a month in storage and
bandwith in and out at Amazon S3 for the same cost as that medium GitHub
account. Of course, bandwidth costs might begin to be a problem if lots of
people accessed that data, whereas I don't recall seeing any bandwidth costs
or limits with GitHub (though, no doubt, they might say something in that
case...)

Of course, most people really don't need anywhere near that much storage or
bandwidth. So, cost may not really be much of an issue for most people in
that sense, compared to community.

Not having tried jGit and Amazon S3, I can't yet see what other issues might
pop up. Anyway, I'm curious how well it would work in practice (in terms of
setting up permissions and such if you were collaborating).

Bryan if you are following this, have you thought about using jGit and
Amazon S3 to host lots of data? Any obvious pitfalls of it? I expect
figuring out how a group might collaborate with that data might be harder
than GitHub?

Still, there are so many free options, and places like GitHub or SourceForge
who do say they will host lots of stuff for free, so, I can see why anyone
would look to free options first.

But in any case, so there are a spectrum of options for hosting open
manufacturing related knowledge sharing projects... And git is one way to
gain access to them (even though other systems like hg or bzr have good
points and hosting too).

Bryan Bishop

unread,
Sep 3, 2010, 3:19:47 PM9/3/10
to openmanu...@googlegroups.com, Paul D. Fernhout, Bryan Bishop
On Fri, Sep 3, 2010 at 12:56 PM, Paul D. Fernhout wrote:
Now, you're probably not going to be giving others access to ssh on your server, but the way git works, you can pull patches from others public sites, or people can email you stuff.

Actually, that's how I've been doing it with gnusha.org. Would you like an account to host some git repos?

git clone git://diyhpl.us/reprap.git

I've also been hosting a wiki there under git:
http://diyhpl.us/wiki/
git clone http://diyhpl.us/diyhpluswiki.git

The same offer goes out to anyone else doing open source hardware stuff under revision control, by the way.

Paul D. Fernhout

unread,
Sep 4, 2010, 9:40:31 AM9/4/10
to Open Manufacturing
Bryan Bishop wrote:
> On Fri, Sep 3, 2010 at 12:56 PM, Paul D. Fernhout wrote:
>
>> Now, you're probably not going to be giving others access to ssh on your
>> server, but the way git works, you can pull patches from others public
>> sites, or people can email you stuff.
>
> Actually, that's how I've been doing it with gnusha.org. Would you like an
> account to host some git repos?

:-)

I was thinking more about the problems of giving out the password to a
single account on a shared hosting (sorry, I was not clear). Obviously, if
someone has an entire server, virtual or physical (as I mentioned later),
you can set up independent accounts for each user. What I meant there was
that I don't see the model of giving out full ssh shell access to multiple
people for a single account scaling much beyond a small tightly-knit group
of a few people because it would be so easy for even a well meaning person
to accidentally mess up the account (a careless editing of a .htaccess file
or messing with the control panel or whatever), or possibly use the server
in some way that gets it shut down, so one might invest time getting used to
doing things one way and then maybe see things break unexpectedly down the
road.

I can definitely see the value of such a thing, say, for a private workgroup
focused on a specific project they were not ready to make public yet (if
they shared one account or if they all had separate gnusha accounts with r/w
access to some common directory with a git repository). Or, I can also see
the value for a specific huge project that needed a lot of disk space or
bandwidth (if gnusha had it). Or maybe if there was some other technical
thing that one wanted to run that gnusha made possible (I'm not sure what
the configuration is) such as running some long running background service
as a specialized server (something that I can't do easily on shared
hosting). On the other hand, using git (or whatever) is in part an attempt
by me to move things back to the desktop (that is, you may share code and
data files using git, but you change them on your desktop usually, even if
you are running ikiwiki or markdown or whatever to create some static html
you rsync somewhere).

When I think about this in the context of public work groups using git and
my own situation and the issues raised in this thread, two issues come to mind:

* Like many people, I already have a public web host somewhere that I could
put public git repositories on (presumably, not having tried it yet) if I
just wanted to stick a gigabyte of FOSS code or content somewhere to share
it. Collaboration is made possible because git allows anyone to copy that
stuff and do what they want with it and then send changes back to me (even
just by a reference to their public repository). So, I'd probably be more
inclined to do that on my own shared hosting account if I was going to just
have an adhoc system using git. Anyone interested in collaborating with me
(in public) could do so very easily without us all sharing a server, and
then I'd have a lot of confidence that I was the only one messing up my own
repository, even if I selectively imported stuff from others. :-) I can see
though, that even with that, if there was some issue of diskspace,
bandwidth, or performance, gnusha might be a good choice over the shared
host I use depending on its configuration (but so far I have not been near
the shared hosting limits).

* If I wanted to work on FOSS code or content in public on using someone
else's system, GitHub says they will provide space for free even beyond
their 0.3GB "soft" limit for free accounts doing FOSS (and there is also
SourceForge or as you mentioned Gitorious). The advantage of using GitHub is
all the social features and the community there (367,000 users right now)
which presumably, no offense, gnusha.org does not have yet on that scale.
Also, forks on GitHub don't seem to incur much of a cost in terms of extra
disk space (or bandwidth for copying) because they are somehow linked to the
original. Granted, GitHub is a programming-oriented community, not a
manufacturing community, so I'm not saying, in the long term, one might not
have something that was like GitHub but with a different (manufacturing)
focus and presumably a somewhat different community; while
http://gnusha.org/ has a somewhat different purpose outlined on the main
page, I can see how it might become such a thing as part of SKDB. But I'm
not sure if such a community could not be on GitHub or Gitorious or
BitBucket (for hg) or Launchpad (for bzr), saving you the headaches of
managing and paying for a server or server farm (or gateway to the cloud) --
even just the point of creating accounts, doing password resets, worrying
about quotas or runaway processes, and so on. Also, I can't run cgi or a
server process on GitHub (although ideally I don't want to anyway -- just
one more thing for me to worry about all the time). So, in that context, I
think focusing on tools that run on top of something like GitHub or one of
those other FOSS hosting providers may be a better investment of time than
emphasizing running a new server (unless the point was that the server was
doing something special, but then that is breaking the model of
collaborating somehow mainly through git). Still, if everyone who got an
account on gnusha agreed to some ground rules about licensing works under
some specific FOSS license (like Savanna), such as, say, all the work was
under the LGPL and CC-BY-SA (just as an example), then that could be a
reason to want to collaborate there (as a statement of intent) similar to
the social dynamics of Wikipedia.

When I paid for a dedicated server for OSCOMAK for a year in relation to
OpenVirgle two+ years ago I discovered a couple obvious-in-retrospect things:
* It's one thing to pay for something for a year, it's another to think
about supporting it indefinitely yourself (a benefit of big public solutions
that already exist like SourceForge) -- especially when there are cheap or
even free solutions around of various sorts;
* Related to the first point, it's hard to extend offers of support to other
groups either to use your hardware or your services unless you're really
confident the system will be around down the road; at the time I thought of
suggesting Appropedia or TMP2 host their wikis on the lightly loaded OSCOMAK
server (their systems were slower then it seemed), but then I thought better
of that and did not suggest that, because where would that leave them if I
decided the next year to downgrade to save money? Which I did after a year,
and I may well get rid of that (second) shared hosting account OSCOMAK is on
entirely now, just keeping static pages exported but hosted elsewhere for
archival reference, since I decided not to use a Halo Semantic MediaWiki and
focus on desktop semantic stuff instead (and likewise move a few other
things incidentally also hosted there like openmanufacturing.net).
* So, I would have been better just giving the money for a dedicated server
to someone (like at the time Doram, Mike, or yourself) who was working on
content or code (or spend it in some other way) rather than pay for a
server. Spending the money on a server with a "build it and they will come"
hope was a choice I regret, especially in Doram's case, as he was looking
for work at the time. It may well be a similar choice you might face if you
decide whether to scale up the gnusha server. Although I doubt my wife would
have gone along with just giving the money to some individual, so that might
have been a non-starter, whereas the server was easier to explain/justify.

For reference, related by me with more details:
http://groups.google.com/group/openvirgle/browse_thread/thread/09c12ead6464db66
"This is an update on the OSCOMAK server, which came out of discussions
here. I just spent a half-hour or so dealing with damage to OSCOMAK from
wikispam. At least someone is using it. :-) The dedicated Semantic
MediaWiki has been a bust as far as spending some significant money on it to
support heavy usage. It's been a learning experience -- mostly learning I
don't want to babysit a server, especially one designed by someone else for
different ends (I felt that already, but it's a reminder). Also, I have not
been confident enough in it to promote it -- both in terms of maintaining a
Semantic MediWiki or in paying for a dedicated server year after year. ..."

But still, if I had spent more time putting content into that MediaWiki than
writing long emails, it still might have been more worthwhile. :-) While
I'll probably never have the time, I'd love to go through my sent email
folder one email at a time and pull out anything I've ever sent to a private
list or private person that could be made public in terms of just what I
wrote (maybe requiring editing to make it general enough, removing quoted
text, and so on and anonymizing or abstracting personal things etc.) so I
could publish it in a blog-ish way on the web, and also ideally organize all
that into some sort of knowledge base divided into topical nuggets without
much redundancy (much like you were doing with your MediaWiki at
heybryan.org). Heybryan.org is not responding at the moment, btw; hey, maybe
you could export that MediaWiki all to pages at GitHub either as HTML or
Markdown? :-)

It's hard to get communities started somewhere, and I don't want to be a
downer about gnusha. I feel the gnusha "Open Hardware Cooperative" idea is a
great concept to be exploring in whatever final form it ends up in. But, as
far as just git hosting goes, gnusha faces the same issue (for me) as when I
think about gitorious, bitbucket (for hg), SourceForge, Google Code (hg),
Savannah, LaunchPad (bzr) and others (including just hosting a git
repository on existing shared hosting), that GitHub is racing ahead in terms
of social momentum as a community of DVCS users within a social context
(even if GitHub is a commercial vendor and also not open source in its
software infrastructure, although neither are the CPUs it is running on).

Of course, the social aspect may not matter if no one there is interested in
a project one puts there, and presumably gnusha would have a least you and
maybe a few people there (although maybe no obvious way to communicate
through the server beyond email or IRC unlike the integrated ways GitHub
has?). But, on the other hand, there may still be many projects at GitHub
I'm interested in somehow (as a programmer), so the social aspect may be of
interest outside of open manufacturing too in ways that overlap (like 3D CAD
software).

Although in practice, one is probably going to interact with all these
services. So, there is probably plenty of room for variety. It's not good to
have a single point of social failure at a place like GitHub (especially
given it is commercial, and so might be bought by Oracle or whoever..).

Anyway, with all that said, it's a generous offer. Thanks. I may take you up
on it one of these days. :-) Especially if it could run some long-running
process as a server and had some specific need for that.

Bryan Bishop

unread,
Sep 4, 2010, 5:47:34 PM9/4/10
to openmanu...@googlegroups.com, Bryan Bishop
On Sat, Aug 28, 2010 at 5:02 PM, Paul D. Fernhout write:
> A question at the end of this about GitHub is mostly directed mostly to
> Bryan, but other should feel free to jump in, too.

Hmm I knew something was weird about all this. That's because we were
having a very similar discussion more than two years ago.

http://groups.google.com/group/openvirgle/browse_thread/thread/58a216b649a1c151/48ab430a20d3dffc

Has anything changed?

Paul D. Fernhout

unread,
Sep 18, 2010, 9:51:43 AM9/18/10
to openmanu...@googlegroups.com

Sorry, I missed your reply until now (two weeks later).

As Alan Newell told me once, in his office, and not in a very complimentary
way, :-) (although he was perhaps still a bit out of it from having
recovered from shingles), sometimes you have to come back to the same idea
several times from different directions before you really understand it or
have made it "yours" in that sense. And I think he had a good point.

What has changed in two years? Mainly a deepening understanding of all that.
Coming back to the same idea from another direction or after having kicked
around other ideas is a sign that the idea has some usefulness.

And also we also now have a better sense of the social momentum in the
society (towards DVCS and stuff like GitHub) as well as toward a "Semanic Web".
http://www.youtube.com/watch?v=TJfrNo3Z-DU
http://metaweb.com/
http://googleblog.blogspot.com/2010/07/deeper-understanding-with-metaweb.html

And you've maybe entirely ditched Perl for Python, to everyone's benefit who
wants to read anything you write? :-)

And I've abandoned the Halo Semantic MediaWiki was trying for OSCOMAK at the
time just to get a quick start. That was a bad idea in retrospect as I just
did not feel good about that direction and it did not give me creative
energy compared to rolling my own system emphasizing different issues. And I
have a newer version of the Pointrel system that can work more easily with
DVCS as it has transactions as independent files?

I can wonder if, as when you commented on Pointrel and "Package relationship
management" back then, that you still may not be generalizing to the point
of seeing SKDB as an application on top of a semantic web (or "The Semantic
Web" if we start seeing that as just one thing like "The Internet").
http://semanticweb.org/wiki/Semantic_Desktop
But I have little doubt that conceptual shift will happen in time, if it has
not already? :-) Still, I may be wrong, and it is possible a stand-alone
approach will get you some success faster?

Anyway, I may post a note to the Diaspora (The "Anti-Facebook" with better
privacy settings and such) mailing list in this regard too, because I think,
as with SKDB, Diaspora perhaps faces the same issue of not yet embracing the
semantic web?

Git itself, for me, with the current Pointrel design is just a convenient
way to have a shared directory (and hg or bzr could do the same, and I also
have other approaches like sftp and CGI). I'm not especially interested at
the moment in branching and merging with a DVCS, because that could be
handled at a level above that by applications using the Pointrel System in
their own way. But that does not mean the git support (or hg or bzr) for
merging might not be useful or eventually essential if one came to depend on
it at that level.

Reply all
Reply to author
Forward
0 new messages