Fossil SCM
Rewrote the "Accepting Contributions" section of the fossil-v-git doc to focus on the size of each tool in terms of SLOC and features, rather than on licensing details.
Commit
5fe84e7011ba6d93695946868269522657e0a7ba60a5d6b716c8acc75464a22d
Parent
34d758bf86b6aba…
1 file changed
+41
-56
+41
-56
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -244,11 +244,11 @@ | ||
| 244 | 244 | |
| 245 | 245 | The Linux kernel has a far bigger developer community than that of |
| 246 | 246 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 247 | 247 | of whom do not know each others names. These thousands are responsible |
| 248 | 248 | for producing roughly 89⨉ more code than is in SQLite. (10.7 |
| 249 | -[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC | |
| 249 | +[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC | |
| 250 | 250 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 251 | 251 | kernel and its development process were already uncommonly large back in |
| 252 | 252 | 2005 when Git was designed, specifically to support the consequences of |
| 253 | 253 | having such a large set of developers working on such a large code base. |
| 254 | 254 | |
| @@ -267,66 +267,51 @@ | ||
| 267 | 267 | not the best way to hang a picture on the living room wall. |
| 268 | 268 | |
| 269 | 269 | |
| 270 | 270 | <h4 id="contrib">2.3.3 Accepting Contributions</h4> |
| 271 | 271 | |
| 272 | -Git is covered by | |
| 273 | -[https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the | |
| 274 | -GPLv2]. Fossil is covered by | |
| 275 | -[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD | |
| 276 | -style license]. Neither license affects the managed repository contents, | |
| 277 | -and it is not our purpose here to try to persuade you to make the same | |
| 278 | -choice of license that we did, but we believe the choice of license has | |
| 279 | -an effect on the actual use of each DVCS. If you don't want to read | |
| 280 | -about licensing, you can skip to [#whylicmat|our point at the end]. | |
| 281 | - | |
| 282 | -The GPL allows a project to do without a | |
| 283 | -[https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor | |
| 284 | -license agreement] (CLA) because by the very act of distributing | |
| 285 | -binaries produced from GPL'd source code, you are bound by the license | |
| 286 | -to also distribute that source code under a compatible license. Some | |
| 287 | -GPL-based projects do require a CLA, but usually only to further | |
| 288 | -commercial interests rather than to maintain the legal integrity of the | |
| 289 | -[https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] | |
| 290 | -project itself. | |
| 291 | - | |
| 292 | -Contrast a BSD-style project, where contributions are not automatically | |
| 293 | -relicensed merely by being distributed along with the preexisting BSD | |
| 294 | -code. Such projects often require a CLA even when there are no corporate | |
| 295 | -interests, to ensure that all contributions are compatibly licensed with | |
| 296 | -the existing body of code. It's a way to add a "no takebacks" clause to | |
| 297 | -the basic BSD license. | |
| 298 | - | |
| 299 | -A CLA makes signing up new contributors harder. It's an extra | |
| 300 | -gatekeeping step, so it discourages low-engagement contributors. The | |
| 301 | -stock GPL requires some of the same relinquishment of rights as Fossil's | |
| 302 | -CLA, and the Git project adds to this | |
| 303 | -[https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an | |
| 304 | -implicit CLA], but contributors agree to both passively. | |
| 305 | -[http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil | |
| 306 | -project's contribution process] requires active steps and processing | |
| 307 | -time: the printing, signing, mailing, reception, and processing of the | |
| 308 | -CLA. | |
| 309 | - | |
| 310 | -<a name="whylicmat"></a> | |
| 311 | -We think there's an upside to this difference in licensing, in Fossil's favor: it | |
| 312 | -improves contributor community cohesion, because everyone who pushed | |
| 313 | -past that legal friction made an affirmative, active step to get commit | |
| 314 | -capability on the Fossil project repository. We believe discouraging | |
| 272 | +As of this writing, Git has received about 4.5⨉ as many commits as | |
| 273 | +Fossil resulting in about 2.5⨉ as many lines of source code. The line | |
| 274 | +count excludes tests and in-tree third-party dependencies. It does not | |
| 275 | +exclude the default GUI for each, since it's integral for Fossil, so we | |
| 276 | +count the size of <tt>gitk</tt> in this. | |
| 277 | + | |
| 278 | +It is obvious that Git is bigger in part because of its first-mover | |
| 279 | +advantage, which resulted in a larger user community, which results in | |
| 280 | +more contributions. But is that the <i>only</i> reason? We believe there | |
| 281 | +are other relevant differences that also play into this which fall out | |
| 282 | +of the "Linux vs. SQLite" framing: licensing, community structure, and | |
| 283 | +how we react to | |
| 315 | 284 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 316 | -contributions] makes for a better, more carefully-designed, simpler | |
| 317 | -DVCS. | |
| 318 | - | |
| 319 | -It's so easy to add features to Git that its command interface has | |
| 320 | -become truly arcane. Masters of the arcane are able to do wizardly | |
| 321 | -things, but only by studying their art deeply for years. This does not | |
| 322 | -strike us as a good use of the user's time. We believe it's better to | |
| 323 | -have a simpler tool with a more easily internalized behavior set, which | |
| 324 | -you can use quickly then set aside in order to get back to your main | |
| 325 | -task of producing the content that you manage in the DVCS. We achieve | |
| 326 | -that by carefully choosing which users to give commit bits to, then which | |
| 327 | -of their feature branches to merge down to trunk. | |
| 285 | +contributions]. In brief, it's harder to get a new feature into Fossil | |
| 286 | +than into Git. | |
| 287 | + | |
| 288 | +Git's larger feature set size is not a good thing. Git's command line | |
| 289 | +interface is famously arcane. Masters of the arcane are able to do | |
| 290 | +wizardly things, but only by studying their art deeply for years. This | |
| 291 | +strikes us as a good thing only in cases where use of the tool itself is | |
| 292 | +the primary point of that user's work. | |
| 293 | + | |
| 294 | +Most DVCS users are not using a DVCS for its own sake, so we do not want | |
| 295 | +the DVCS with the most features but the one that lets us get back to our | |
| 296 | +actual job as quickly as possible. There is some minimal set of features | |
| 297 | +required to achieve that, but there is a level beyond which more | |
| 298 | +features only slow us down when we're trying to figure out how to get | |
| 299 | +past our latest battle with the DVCS. When the number of features grows | |
| 300 | +to the point where people of normal motivation cannot spend the time to | |
| 301 | +master them all, you make the tool <i>less</i> productive to use. | |
| 302 | + | |
| 303 | +We believe it's better to have a simpler tool with a more easily | |
| 304 | +internalized behavior set, which you can pick up, use quickly, then set | |
| 305 | +aside in order to get back to your main task: producing the content that | |
| 306 | +you manage in the DVCS. We achieve that by carefully choosing which | |
| 307 | +users to give commit bits to, then which of the feature branches they | |
| 308 | +create to merge down to trunk. | |
| 309 | + | |
| 310 | +Fossil more closely adheres to | |
| 311 | +[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the | |
| 312 | +principle of least astonishment] than Git does. | |
| 328 | 313 | |
| 329 | 314 | |
| 330 | 315 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 331 | 316 | |
| 332 | 317 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 333 | 318 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -244,11 +244,11 @@ | |
| 244 | |
| 245 | The Linux kernel has a far bigger developer community than that of |
| 246 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 247 | of whom do not know each others names. These thousands are responsible |
| 248 | for producing roughly 89⨉ more code than is in SQLite. (10.7 |
| 249 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC |
| 250 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 251 | kernel and its development process were already uncommonly large back in |
| 252 | 2005 when Git was designed, specifically to support the consequences of |
| 253 | having such a large set of developers working on such a large code base. |
| 254 | |
| @@ -267,66 +267,51 @@ | |
| 267 | not the best way to hang a picture on the living room wall. |
| 268 | |
| 269 | |
| 270 | <h4 id="contrib">2.3.3 Accepting Contributions</h4> |
| 271 | |
| 272 | Git is covered by |
| 273 | [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the |
| 274 | GPLv2]. Fossil is covered by |
| 275 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 276 | style license]. Neither license affects the managed repository contents, |
| 277 | and it is not our purpose here to try to persuade you to make the same |
| 278 | choice of license that we did, but we believe the choice of license has |
| 279 | an effect on the actual use of each DVCS. If you don't want to read |
| 280 | about licensing, you can skip to [#whylicmat|our point at the end]. |
| 281 | |
| 282 | The GPL allows a project to do without a |
| 283 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 284 | license agreement] (CLA) because by the very act of distributing |
| 285 | binaries produced from GPL'd source code, you are bound by the license |
| 286 | to also distribute that source code under a compatible license. Some |
| 287 | GPL-based projects do require a CLA, but usually only to further |
| 288 | commercial interests rather than to maintain the legal integrity of the |
| 289 | [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] |
| 290 | project itself. |
| 291 | |
| 292 | Contrast a BSD-style project, where contributions are not automatically |
| 293 | relicensed merely by being distributed along with the preexisting BSD |
| 294 | code. Such projects often require a CLA even when there are no corporate |
| 295 | interests, to ensure that all contributions are compatibly licensed with |
| 296 | the existing body of code. It's a way to add a "no takebacks" clause to |
| 297 | the basic BSD license. |
| 298 | |
| 299 | A CLA makes signing up new contributors harder. It's an extra |
| 300 | gatekeeping step, so it discourages low-engagement contributors. The |
| 301 | stock GPL requires some of the same relinquishment of rights as Fossil's |
| 302 | CLA, and the Git project adds to this |
| 303 | [https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an |
| 304 | implicit CLA], but contributors agree to both passively. |
| 305 | [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil |
| 306 | project's contribution process] requires active steps and processing |
| 307 | time: the printing, signing, mailing, reception, and processing of the |
| 308 | CLA. |
| 309 | |
| 310 | <a name="whylicmat"></a> |
| 311 | We think there's an upside to this difference in licensing, in Fossil's favor: it |
| 312 | improves contributor community cohesion, because everyone who pushed |
| 313 | past that legal friction made an affirmative, active step to get commit |
| 314 | capability on the Fossil project repository. We believe discouraging |
| 315 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 316 | contributions] makes for a better, more carefully-designed, simpler |
| 317 | DVCS. |
| 318 | |
| 319 | It's so easy to add features to Git that its command interface has |
| 320 | become truly arcane. Masters of the arcane are able to do wizardly |
| 321 | things, but only by studying their art deeply for years. This does not |
| 322 | strike us as a good use of the user's time. We believe it's better to |
| 323 | have a simpler tool with a more easily internalized behavior set, which |
| 324 | you can use quickly then set aside in order to get back to your main |
| 325 | task of producing the content that you manage in the DVCS. We achieve |
| 326 | that by carefully choosing which users to give commit bits to, then which |
| 327 | of their feature branches to merge down to trunk. |
| 328 | |
| 329 | |
| 330 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 331 | |
| 332 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 333 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -244,11 +244,11 @@ | |
| 244 | |
| 245 | The Linux kernel has a far bigger developer community than that of |
| 246 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 247 | of whom do not know each others names. These thousands are responsible |
| 248 | for producing roughly 89⨉ more code than is in SQLite. (10.7 |
| 249 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC |
| 250 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 251 | kernel and its development process were already uncommonly large back in |
| 252 | 2005 when Git was designed, specifically to support the consequences of |
| 253 | having such a large set of developers working on such a large code base. |
| 254 | |
| @@ -267,66 +267,51 @@ | |
| 267 | not the best way to hang a picture on the living room wall. |
| 268 | |
| 269 | |
| 270 | <h4 id="contrib">2.3.3 Accepting Contributions</h4> |
| 271 | |
| 272 | As of this writing, Git has received about 4.5⨉ as many commits as |
| 273 | Fossil resulting in about 2.5⨉ as many lines of source code. The line |
| 274 | count excludes tests and in-tree third-party dependencies. It does not |
| 275 | exclude the default GUI for each, since it's integral for Fossil, so we |
| 276 | count the size of <tt>gitk</tt> in this. |
| 277 | |
| 278 | It is obvious that Git is bigger in part because of its first-mover |
| 279 | advantage, which resulted in a larger user community, which results in |
| 280 | more contributions. But is that the <i>only</i> reason? We believe there |
| 281 | are other relevant differences that also play into this which fall out |
| 282 | of the "Linux vs. SQLite" framing: licensing, community structure, and |
| 283 | how we react to |
| 284 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 285 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 286 | than into Git. |
| 287 | |
| 288 | Git's larger feature set size is not a good thing. Git's command line |
| 289 | interface is famously arcane. Masters of the arcane are able to do |
| 290 | wizardly things, but only by studying their art deeply for years. This |
| 291 | strikes us as a good thing only in cases where use of the tool itself is |
| 292 | the primary point of that user's work. |
| 293 | |
| 294 | Most DVCS users are not using a DVCS for its own sake, so we do not want |
| 295 | the DVCS with the most features but the one that lets us get back to our |
| 296 | actual job as quickly as possible. There is some minimal set of features |
| 297 | required to achieve that, but there is a level beyond which more |
| 298 | features only slow us down when we're trying to figure out how to get |
| 299 | past our latest battle with the DVCS. When the number of features grows |
| 300 | to the point where people of normal motivation cannot spend the time to |
| 301 | master them all, you make the tool <i>less</i> productive to use. |
| 302 | |
| 303 | We believe it's better to have a simpler tool with a more easily |
| 304 | internalized behavior set, which you can pick up, use quickly, then set |
| 305 | aside in order to get back to your main task: producing the content that |
| 306 | you manage in the DVCS. We achieve that by carefully choosing which |
| 307 | users to give commit bits to, then which of the feature branches they |
| 308 | create to merge down to trunk. |
| 309 | |
| 310 | Fossil more closely adheres to |
| 311 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 312 | principle of least astonishment] than Git does. |
| 313 | |
| 314 | |
| 315 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 316 | |
| 317 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 318 |