3 ms·

github's where the people are. Everyone already has a github account. Either way git itself means there isn't too much vendor lock-in, just the ancillary parts

by cp9 10y ago

github's where the people are. Everyone already has a github account. Either way git itself means there isn't too much vendor lock-in, just the ancillary parts of the project (issues, wiki, project site)

sytse 10y ago
The network effect for user accounts matters most when you have an open source project with a large audience, for private projects it is less important I think.
stephenr 10y ago
I still find this argument hard to follow. You have a person who wants to contribute code to you open source project, but that person is stymied by requiring an account on a service other than GitHub. What kind of people are you expecting to be doing drive-by code contributions and what kind of code quality are you expecting from them?
- zardeh 10y ago
  "I don't want to have to jump through hoops to contribute to your project". I've made a few OSS contribs that were fork, clone and edit locally (or edit online in one case), push, test, pull request. That was all, they took ~20 minutes, if that. Adding in "create an account", "figure out the new UI's method of forking/pulling", and "link myself to another random webservice that I'll only use once" is too much friction, I might spend as much time setting up the account as actually making the edit. Sure, if I'm planning to become a contributor to a large project (like, say python, which isn't on gh), I'll go ahead and make an account on the bugtracker and join the mailing list and learn how the hell mercurial works. That's fine if I expect to make 10+ commits to a project and really delve deep into it. But most projects aren't big. Most projects aren't that interesting. OSS thrives on people fixing the one bug they encounter (seriously, look at the bus number of major projects). Adding friction in the process is bad for that software.
  - dmitry-k 10y ago
    @zardeh Totally agree in that adding friction is bad. At Rhodecode, we tried to eliminate it, by creating a dedicated page for contributors (https://rhodecode.com/open-source https://rhodecode.com/open-source) and allowing to login via GitHub / BitBucket. One more point: although the contributions are not made for the recognition alone, a bit of it never hurts. We ended up with a badge system for https://community.rhodecode.com https://community.rhodecode.com , where code contributors get rights to moderate discussions (since they ARE the core users of RhodeCode).

by cp9 10y ago

sytse 10y ago

The network effect for user accounts matters most when you have an open source project with a large audience, for private projects it is less important I think.

stephenr 10y ago

I still find this argument hard to follow. You have a person who wants to contribute code to you open source project, but that person is stymied by requiring an account on a service other than GitHub. What kind of people are you expecting to be doing drive-by code contributions and what kind of code quality are you expecting from them?

zardeh 10y ago
"I don't want to have to jump through hoops to contribute to your project". I've made a few OSS contribs that were fork, clone and edit locally (or edit online in one case), push, test, pull request. That was all, they took ~20 minutes, if that. Adding in "create an account", "figure out the new UI's method of forking/pulling", and "link myself to another random webservice that I'll only use once" is too much friction, I might spend as much time setting up the account as actually making the edit. Sure, if I'm planning to become a contributor to a large project (like, say python, which isn't on gh), I'll go ahead and make an account on the bugtracker and join the mailing list and learn how the hell mercurial works. That's fine if I expect to make 10+ commits to a project and really delve deep into it. But most projects aren't big. Most projects aren't that interesting. OSS thrives on people fixing the one bug they encounter (seriously, look at the bus number of major projects). Adding friction in the process is bad for that software.
- dmitry-k 10y ago
  @zardeh Totally agree in that adding friction is bad. At Rhodecode, we tried to eliminate it, by creating a dedicated page for contributors (https://rhodecode.com/open-source https://rhodecode.com/open-source) and allowing to login via GitHub / BitBucket. One more point: although the contributions are not made for the recognition alone, a bit of it never hurts. We ended up with a badge system for https://community.rhodecode.com https://community.rhodecode.com , where code contributors get rights to moderate discussions (since they ARE the core users of RhodeCode).