WRONG. GitHub gets its popularity from virtually everything other than the above.
mostly, since GitHub is used primarily for code repositories (as intended), ppl searching for „<insert_project_here> source code” will hit a repository of this kind. then there’s the snowball effect of increasing popularity, due to ppl tending to choose whatever is already popular.
there is no established practice for anyone to search for „open source game asset development repository”. if anything (relevant), one searches for „GrangerHub asset development repository”, but only after finding out that such a thing exists, obviously through grangerhub.org or an intermediary, but then the wishfully thought „increased exposure” is null.
i never said that having to agreeing to a ToS makes for an „overkill”; this wouldn’t even make sense. in general, an „overkill” is the employment of an overly sophisticated tool to deal with a relatively simple task.
a version control system (VCS) is a suite for code development, especially maintenance, in which relatively small, local changes r made to a code base, coupled with annotations (eg. for every change, a summary of what the change does); VCSs encode the changes compactly (in terms of data size), making the storage of full histories rather affordable, which is necessary for accounting and tracking down changes (eg. who fuck the code up recently).
a VCS for accumulation of assets is an overkill. overkills have general downsides, and there r some specific ones too.
- generally, overkills r cumbersome to learn, to set up and to use. it takes time and effort to get into using a VCS, and Git in particular has a steep learning curve; this is accentuated by the fact that non-coders will tend to find the VCS thing new to them. this may phase out potential contributors.
- specifically, like most VCSs, Git incorporates a linear history model, by which the changes r chained in chronological order, and the implemented „easily reachable” history operations r of the form „set the state, of the whole file&directory-hierarchy, to that of key point #266 in the history of changes”, as opposed to „compose, into the file&directory-hierarchy, the changes (adding new or alternative things) ξ, ξ₁ and Δ, but not the changes ξ₂ and Ω”. to understand why the latter would have been preferrable, imagine the following linear history of changes:
- (older changes)
- #266: „lower the polygon count of the range marker shapes, to increase framerates”1
- #267: „import high-resolution textures for the pampers wearable”
- #268: „import a new flamethrower model”
- #269: „revert the range marker shape change, because it was a fuckup”1
- #270: „import a new armory model”
- (newer changes)
with such a history, if one wants to see the old flamethrower model, but high-resolution pampers textures, one only has the „easily reachable” option to set the state to that of #267; unfortunately, that state has broken range marker shapes, and also has the old armory model. instead, one would want a changes to be organizable as a partially dependent collection; imagine:
- ξ: „import new naked human, light armor and helmet models”
- ξ₀: „import high-resolution textures for the new naked human”
- ξ₁: „import high-resolution textures for the new light armor”
- ξ₂: „import high-resolution textures for the new helmet”
- Ω: „import a new armory model”
- (other changes)
in this, use of (at least one of) ξ₀, ξ₁ and ξ₂ requires ξ; ie., the use of high-resoluton textures — for the new human variants — logically requires the use of the new human models; but then any combination of ξ₀, ξ₁ and ξ₂ may be used; and whether or not to use the new armory model is yet another independent option. again, Git has no such organization feature.
one could always manually copy-in asset files as wanted, but then what is Git for ?2
- generally, overkills waste resources. asset changes generally come in „blobs”: either a new asset is added, or a previous asset is completely replaced with a new one; here, assets r binary files. this effectively forces any VCS to store all versions of an asset (not compact), occupying data space. this is coupled with the fact that assets usually don’t need history analysis, thus new contributors will usually end up downloading and storing all old assets, but using only the latest ones. (exceptions r shaders and game-configuration files, which r not binary files.)
1 true story. goddamn DICKBUTTs…
2 this tends to be not too much of a crippling for code management, because very often a code change relies on a previous one, making the earlier change either impossible to systematically undo (or otherwise edit), or would result in a compilation failure or runtime error; this is in contrast with assets, where each texture, geometric object, etc. can be changed without breaking anything.
i don’t recall when i read the GitHub ToS last time, but as with all big-company ToSs, by using the service, u’re selling part of ur life to the company and (since it is USA-based) to the NSA too, and r setting an effective precedent for others to do the same.