When I was first getting started with open source development, the de-facto standard hosting place was SourceForge. It was never perfect, but it provided basic web hosting, source control (in those days, everything was svn or cvs), wiki, bug tracker, etc.
SourceForge had a lot of momentum in those days. Somehow, though, over the course of 10 or 15 years, things just went wrong for the site. It started requiring more and more clicks to download anything, and more and more ads started popping up. Now it's pushing malware installers, at least according to this article on gluster's blog. http://blog.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/ Other competitors popped to try to take on the mantle of best open source hosting site. Google Code (now shutting down), BitBucket, now Github. I've used 'em all. I have repos hosted on SourceForge, BitBucket, Github, and Google Code. (Which reminds me, I have to migrate the projects I still have on Google Code soon...) What I found is that putting stuff up on github doesn't guarantee pull requests, or really any kind of community engagement. I think I've gotten a grand total of 3 pull requests for my github repos over the last 5 years. And the repos that I got pull requests for were ones that I gave talks on at conferences, or talked to co-workers about. HTrace's own experience was similar... we had very few contributors back in the github days. In my experience, a quiet fade into obscurity is the fate of most github projects. Getting people interested and contributing to projects requires stepping away from the computer and interacting with them on a personal level, not whiz-bang software. I think the most important thing that github provides projects with is a standard landing page, a standard way to contact the author, and a standard way to send in patches. If you are just perusing someone's private website, it may not be obvious how to contact them or what format to send the patches in. Github alleviates that problem. For HTrace, we already have our own landing page, our own mailing list and bug tracker, and our own conventions about how to send in patches. Github adds a lot less value for us. The idea that projects get popular because of where they host their code or what software they use to do reviews seems really questionable to me. Some of the most popular projects, like the Linux kernel, have really esoteric review systems (i.e. sending in carefully formatted patches to a mailing list). Hadoop is another example... we have a lot of antiquated practices like CHANGES.txt, but still get a lot of contributors. JIRA adds a lot of value for us because it lets us search discussions that go back potentially years. On Hadoop, I often find myself referring to old discussions to see why something was done one way or another. I also use it to see what is in one release or another release (it can search by version). It can do searches across multiple projects (In JQL terms, "project = hadoop or project = htrace and ...") JIRA is also a place where people can comment even if they are not developers. If they are users who just want to see something fixed, they can comment on the jira asking what is going on with the issue. Or they can open a JIRA to suggest a feature, link one JIRA to another, etc. Yes, JIRA comments are mirrored to email, but the mirroring is a pretty lossy process. You can't search emails by version, or across projects, or in any structured way. If we can have github comments mirrored to JIRA as you describe, maybe it's not so bad. But it's not so good either. Looking at that JIRA conversation, I find it a bit harder to follow than a "standard" one. The software seems to be quoting huge amounts of code context, making it a little bit tougher to follow. A human would have only quoted the lines he was interested in. And I wonder whether, if I made a comment on the JIRA, the person would see it, or whether he'd only be following the github. In other words, is the mirroring two-way? I don't know. I have to think about this more. If there is really a huge demand by people outside the project to use github, and we have JIRA integration, then maybe it could work. So far all of the demand seems to be from people who are already contributors. This makes me think that something like Crucible would actually be a better fit, since it fits into our existing workflow rather than grafting a 3rd-party website to it. best, Colin On Sun, Apr 26, 2015 at 12:36 PM, Nick Dimiduk <[email protected]> wrote: > For reference, here's a ticket [0] from Phoenix which makes used of the > Github PR integration. As you can see, the PR comments are posted on the > JIRA. In this regard, it's actually easier to track patch comments than in > RB, by simply looking at the JIRA comments. > > [0] https://issues.apache.org/jira/browse/PHOENIX-628 > > On Fri, Apr 24, 2015 at 11:38 AM, Roman Shaposhnik <[email protected]> > wrote: > >> On Tue, Apr 21, 2015 at 6:18 PM, Nick Dimiduk <[email protected]> wrote: >> > There's a joke here about N devs in a room and N opinions that are all >> > right (and all wrong)! >> >> Isn't the lower bound on the number of opinions at least N^2? >> >> > All I'm asking for here is to make it easy for outsiders to contribute. >> > Having HTrace show up in the mirror is a big step. The next logical thing >> > is folks will click the fork button. We should be ready to receive the >> > incoming help; the details of that implementation are less important to >> me. >> >> That's all posible today. >> >> > Whatever our individual opinions, GH is a defacto place for developers >> > these days -- their tools are extremely well socialized. It's a shame to >> > cut ourselves off from users of that community. I happen to share Colin's >> > opinions about the inferiority of GH's interface for historical comments >> (I >> > personally like gerrit the best of the tools I've used), but that doesn't >> > mean we should shun it. (I also generally loath JIRA, on par with >> Elliott's >> > thoughts). >> >> FWIW: I have seen how enabling GH workflow helps increase >> the # of meaningful contributions coming in. Apache Groovy (incubating) >> is a prime example of a project that runs as close to pure GH workflow >> as is possible within ASF. >> >> Thanks, >> Roman. >>
