Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
On maintenance of clahub and clahub.com #111
It's clear that I'm failing to maintain this project, and I don't think the situation will improve. I would like to share my thoughts and propose some ways forward to improve the situation, and welcome others' thoughts on this.
There are two separate things in question: the public shared instance at https://www.clahub.com, and the the code here on GitHub.
I'm the only person currently able to roll updates to clahub.com and do a poor job of it, so we should find a different approach.
One option would be finding a willing maintainer and transferring ownership of the domain and hosting there. I am uncomfortable with disclosing access to the data (user GH tokens and contributor signature information), so I don't think this is a good idea. I feel that it would violate the trust of people who have signed up and submitted information to the site so far.
A second option would be a person or organization volunteering to run a new public shared instance. Given a hypothetical new public instance, I think that the transition could be made relatively painless if it also included a way to import the CSV signatures that the current software can export.
A third option would be to not host any public shared instance, and ship CLAhub solely for use for individual projects or organizations. (Honestly, back in 2012 I thought that would be the primary form of use!)
While it's completely possible to decouple the maintenance of the FOSS project from maintenance of a public shared instance, it's challenging (impossible?) for people who do not have access to clahub.com to triage and debug issues like #108, #109, #110 as they can't access server logs and inspect the errors, so these activities probably go hand-in-hand -- at least one maintainer should run the public instance, too, if there is to be one.
Thoughts? (I'm away for the long weekend, but promise to follow up on any discussion on this thread next week when I'm back.)
I, for one, really appreciate what you have done. I think that right now, there is a lot of benefit in option three - I think that also addresses the issue with contributors needing to hand off their application keys...because they would only be in association with a specific project.
Also, as for the bugs that happen, if someone is being bitten by them, it is a lot easier if they have access to their own servers.
Finally, there is nothing precluding someone from taking the code and setting up their own public (free or charged) service. I appreciate what you have done so far, but I'm pretty sure our legal teams would actually prefer to run such a sensitive service in-house.
If possible, I would suggest that you spend whatever limited time you have in helping to get the current code base documented to the point where someone could get it running in their own server. To be honest, I haven't looked into the details of what is currently there, but I'd be willing to help out where needed in getting it to a point where it could be self hosted.
I also appreciate the effort that has gone into maintaining this project and (even more) into maintaining the instance. Thanks for that, and for being transparent about this.
I wanted to make a note of a new feature that would be important in the event that you decide to take down the service: an "import signatures" function. This will allow users migrating from the "public" instance on clahub.com to their own instance to retain their data.
So funny story but I'm working on a very similar open source app at HelloSign using our embedded signing API for e-signatures (https://github.com/freddyrangel/HelloCLA). The idea was to have something that does what clahub does but include some other features (for example, automatically checking authors of PRs to see if they signed a CLA and if they haven't, post a comment asking them to sign a CLA). I could float around the idea about having HelloSign take over the project, if that's something you guys are open to. Our team is really excited about CLAs and how HelloSign can help solve that problem.
I agree that would be confusing. The thing is, I just created jasonm/clahub-org-test2#1 and created a CLA and it worked as expected, so it's not an issue of going in and flicking switches on some process. And, looking at the logs, the service is working as expected for a large number of users.
The work to be done here is understanding what cases aren't working, producing a reproducible test case, and writing the patch to cover some case that the current codebase doesn't cover. Same as it has been for the last several patches. This is the work I don't have the bandwidth/interest to take on anymore.
It's also not an issue of me being able to afford the $50/mo hosting, which I have freely footed for two years now.
@toonetown @jugglinmike & @freddyrangel thanks for the kind words. Since I don't personally use this service anymore, all the incentive to work on it and pay for it comes from wanting to help people out, so this goes a long way! I appreciate your input.
Totally agree :)
I have tried to keep https://github.com/clahub/clahub/blob/master/DEPLOY.md up to date with various changes, and the app should run sufficiently on the Heroku free tier. For other environments, @jugglinmike has contributed a
This makes a lot of sense. I've opened #112 to discuss - I'm happy to merge a PR for this and deploy it. There is a slightly challenging caveat there, but it seems surmountable.
@freddyrangel - very interesting! We are happy users of HelloSign at my day job. I think it's a great use case. Do you intend for users to install & self-host, or to maintain a SaaS installation?
It might make sense for HelloCLA to remain a HelloSign-branded and maintained project, although I'm very happy for you to reuse any CLAhub code or use it as a reference. Also happy to refer to HelloCLA as a recommended service given that I'd like to wind down CLAhub.
We discussed the comment-to-invite functionality for CLAhub, although that was primarily driven by an older version of GitHub's Statuses API which didn't support multiple services indicating status, so one could not use CLAhub in addition to e.g. TravisCI.
@jasonm - That's great to hear :) So, I started building HelloCLA from scratch last week only because CLAhub seemed under-maintained. Originally I considered just contributing to CLAhub and offering a free HelloSign API subscription but I wasn't sure the PR would get looked at.
Ideally I'd like to not duplicate effort by working on an identical project and just focus on making CLAhub really awesome. Our company has grown pretty rapidly and part of my job now is contributing to open source. I'd like to be one of the maintainers but I also think you should add some non-HelloSign peeps as maintainers as well if you can.
@jasonm I was notified the clahub site was down and it pointed to this issue. I just read through this issue. I appreciate the work on CLAHub, it's been great for my needs! Are you planning on shutting it down or is this a known/unplanned outage? If shutting down, I'd appreciate any opportunity to export a final list of the folks who have signed.
@jtnelson Excellent news!
If it was up to me (it is not:), I would start by reviewing all the github forks of clahub and merging relevant improvements, there are quite a few.
I tried contacting @hybridgroup and @strongloop-forks about licensing info of their changes (they made quite a few, albeit many of them quite their-company-specific), but unfortunately there was no response.
I would be willing to invest some of my time into this project (second half of september, october), especially in the area of CLA editing, versioned CLAs and tracking which user signed which version, or alternatively, using git existing or dedicated git repo for current CLA content and version retrieval. This later alternative (hosting CLA content within git repo) seems more elegant option, as it relieves ClaHub of all CLA editing responsibilities, and must only tracks pushes to git repo that contains the CLA.
Also, if base ClaHub would provide some CLA templates to start from, that would be splendid, but IANAL to create one from scratch.
Comments welcome :)
@bostjan With respect to versioned CLAs, I would like to eventually do some refactoring and use Concourse, the database I maintain (see https://github.com/cinchapi/concourse) as the backing store. Concourse natively versions data, so we would get CLA editing, versioning and diffing for free. We'd also be able to expose a lot of nice analytics features for users so they can see more in depth information about contributors and how that changes over time.
Hi, I was thinking about using clahub for our project, but the lack of a motivated maintainer is worrisome. I'm not interested in becoming a maintainer myself, however, as far as the hosting fee is concerned, perhaps you could contact OSU's Open Source Lab -- they provide free hosting for open source projects. I have never contacted them myself, but I would hate to see you shut down the site or have to continue to pay out of pocket for hosting.
referenced this issue
Nov 30, 2015
referenced this issue
Jan 31, 2016
Feb 13, 2016
I'd like to extend my sincere thanks for your support. Particular thanks to the several individuals who have volunteered to maintain CLAhub both on this thread and elsewhere.
I am excited to share that the Berkman Center for Internet and Society at Harvard University @berkmancenter has volunteered to maintain CLAhub.
Their initial work has been to review, prioritize, and begin to work on existing issues and further feature development. The plan is to also share access and administration of the https://clahub.com hosting to support Berkman's work and eventually transition maintenance of the publicly hosted instance.
From there they hope to be able to leverage their relationship with the Cyberlaw Clinic at Harvard Law School to figure out a Creative Commons-style approach to CLAs, so that project maintainers can easily pick an effective CLA during setup and contributors can easily understand what they are agreeing to.