Fossil SCM
Edit pass on the whyallinone.md doc.
Commit
2b76ea2b17d20767b5d7033b4f923f502ebf90b39749737eeced02420b72d3e2
Parent
5289bf4a315c214…
1 file changed
+51
-37
+51
-37
| --- www/whyallinone.md | ||
| +++ www/whyallinone.md | ||
| @@ -14,11 +14,11 @@ | ||
| 14 | 14 | |
| 15 | 15 | > *I don't want forum/web software built into my dvcs.* |
| 16 | 16 | > *I don't see how this improves over git.* |
| 17 | 17 | |
| 18 | 18 | This commenter may hold whatever opinions he wishes, of course. |
| 19 | -However, here are a few reasons why bundling other project management | |
| 19 | +However, there are many good reasons why bundling other project management | |
| 20 | 20 | features with the DVCS might be useful for a given project: |
| 21 | 21 | |
| 22 | 22 | 1. There is single software package to install and manage for the |
| 23 | 23 | project website. |
| 24 | 24 | The alternative is to select, install, configure, learn about, |
| @@ -26,11 +26,11 @@ | ||
| 26 | 26 | ticketing, forum, |
| 27 | 27 | chat, documentation, and whatever other software packages your project needs. |
| 28 | 28 | Less time spent on project administration details means more |
| 29 | 29 | time available to spend on the project itself. |
| 30 | 30 | |
| 31 | - 2. Because of Fossil’s autosync feature, you get a backup of the | |
| 31 | + 2. Fossil’s autosync feature gives you an implicit backup of the | |
| 32 | 32 | wiki, tickets, forum, and so forth simply by cloning the |
| 33 | 33 | repository to another machine and using that clone regularly. |
| 34 | 34 | Since the typical Fossil usage pattern is to stand the repo up on a |
| 35 | 35 | central server and have the developers clone that repository down |
| 36 | 36 | to their personal machines, if the server falls over, the last |
| @@ -107,11 +107,11 @@ | ||
| 107 | 107 | |
| 108 | 108 | 5. The forum and chat features of Fossil are disabled by default, and |
| 109 | 109 | you can disable the ticket-tracking and wiki features with a quick |
| 110 | 110 | configuration change to its [role-based access control |
| 111 | 111 | system](./caps/), allowing you to treat Fossil as a more direct |
| 112 | - drop-in for Git. When you’re ready to turn these features on, you | |
| 112 | + drop-in for Git. When you’re ready to turn these additional features on, you | |
| 113 | 113 | can do so with a few mouse clicks. |
| 114 | 114 | |
| 115 | 115 | Because Fossil is web-native out of the box, if you’ve delegated |
| 116 | 116 | these features to outside systems to flesh out Git’s DVCS-only |
| 117 | 117 | nature, Fossil can link out to these systems, and they back into |
| @@ -135,86 +135,100 @@ | ||
| 135 | 135 | Take the first two points above: standing up a Fossil repo backup |
| 136 | 136 | on a new server may be as simple as copying the backup to the new |
| 137 | 137 | server and [configuring its stock HTTP server to point at the |
| 138 | 138 | backup repository via CGI](./server/any/cgi.md). |
| 139 | 139 | |
| 140 | - Consider: if you had good backups for all of the elements in a | |
| 140 | + Consider: If you had good backups for all of the elements in a | |
| 141 | 141 | Git + [Jira] + [Discord] + [MediaWiki] + [Sphinx] lash-up, how long |
| 142 | 142 | would it take you to stand up a replacement? That lash-up |
| 143 | - certianly has more features combined than Fossil alone, but are | |
| 143 | + certainly has more features combined than Fossil alone, but are | |
| 144 | 144 | they worth the administration and hosting costs they impose? |
| 145 | + Fossil’s feature set suffices for the SQLite project it was | |
| 146 | + created to serve, as well as for many others; is your project | |
| 147 | + sufficiently more complex, such that it *needs* all of those extra | |
| 148 | + features and their concomitant complexity? | |
| 145 | 149 | |
| 146 | 150 | Considerations such as these push many into centralized hosting |
| 147 | 151 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 148 | 152 | just takes you back to point 3 above. |
| 149 | 153 | |
| 150 | 154 | 8. Hosting all of these elements within a single service gives a |
| 151 | 155 | consistent look-and-feel across all aspects of the project. |
| 152 | 156 | |
| 153 | - This goes deeper than simply skinning independent software | |
| 154 | - elements, though that’s a big enough problem by itself. If you use | |
| 155 | - a separate DVCS front end, chat system, forum manager, | |
| 156 | - documentation system, ticket tracker, and so on, you are likely to | |
| 157 | - be relegated to simply matching colors and fonts; you might also | |
| 158 | - be able to add a common logo to the header of all of these | |
| 159 | - independent pieces. Without heroic levels of local customization, | |
| 160 | - the pieces won’t look unified, because they weren’t developed that | |
| 161 | - way. | |
| 162 | - | |
| 163 | - The Fossil project not only has a single central development focus | |
| 164 | - resulting in a unified web UI design, it gives you a common | |
| 157 | + Skinning independent software packages’ web interfaces to make | |
| 158 | + them appear unified is more work than skinning everything once, as | |
| 159 | + in Fossil, and even then, you can’t make independently-developed | |
| 160 | + software look like it was produced by a single entity without | |
| 161 | + resorting to heroic levels of customization. If you use a separate | |
| 162 | + DVCS web front end, chat system, forum manager, documentation | |
| 163 | + system, ticket tracker, and so on, you are likely to be relegated | |
| 164 | + to simply matching colors and fonts; you *might* also get the | |
| 165 | + ability to add a common logo to the header of all of these | |
| 166 | + independent pieces. The pieces won’t look unified, because they | |
| 167 | + weren’t developed that way. | |
| 168 | + | |
| 169 | + The Fossil project, being a unified software development effort, | |
| 170 | + not only offers a unified web UI design, it gives you a common | |
| 165 | 171 | skinning system for all of its elements so that if you want to |
| 166 | 172 | customize its appearance, your improvements affect all elements of |
| 167 | 173 | Fossil. |
| 168 | 174 | |
| 169 | 175 | Or not: there’s a feature in Fossil that lets skin customizations |
| 170 | 176 | apply to only *some* Fossil features. The initial impetus behind |
| 171 | 177 | this feature was that one of our users wanted Markdown to be |
| 172 | 178 | rendered with different indentation in forum posts than in |
| 173 | - embedded documentation owing to the inherent differences between | |
| 174 | - the two presentation modalities. Yet, when a user taking advantage | |
| 175 | - of this feature wishes to change a UI element common to all Fossil | |
| 176 | - features — say, to change the font for literal code blocks — they | |
| 177 | - can still make that sort of global change, the per-feature CSS | |
| 178 | - inheriting all skin changes it doesn’t explicitly override. | |
| 179 | - | |
| 180 | - Speaking of Markdown, unifying all of these features within Fossil | |
| 179 | + [embedded documentation][edoc] owing to the inherent differences between | |
| 180 | + the two presentation modalities. | |
| 181 | + | |
| 182 | + A user taking advantage of this per-feature CSS capability who | |
| 183 | + wishes to change a UI element common to all Fossil features — say, | |
| 184 | + to change the font for literal code blocks — may still make such a | |
| 185 | + change globally. Opting into this per-feature CSS doesn’t fork all | |
| 186 | + skinning efforts: UI elements not explicitly reskinned on a | |
| 187 | + per-feature basis inherit the global skinning. | |
| 188 | + | |
| 189 | + But it goes futher. Fossil has a feature for [project-specific | |
| 190 | + extensions](./serverext.wiki), which backs the [SQLite Release | |
| 191 | + Checklist][srckl], for instance. You wouldn’t know by looking at | |
| 192 | + that page that it’s produced by software that isn’t actually part | |
| 193 | + of Fossil: the extension only delivers the core of the page, | |
| 194 | + and Fossil’s skining wraps it in a way that lets it inherit all of | |
| 195 | + the project-level skinning customizations. | |
| 196 | + | |
| 197 | + 9. Unifying all of these features within Fossil | |
| 181 | 198 | means we have a single Markdown interpreter common to all |
| 182 | 199 | elements. If you lash multiple software systems together, even if |
| 183 | 200 | they can all agree on Markdown as a common document markup |
| 184 | 201 | language — hardly a given, as shown by the MediaWiki and Sphinx |
| 185 | 202 | elements in point 7 above — they’re likely to render your text |
| 186 | 203 | using different — possibly even incompatibly-different — Markdown |
| 187 | 204 | dialects. |
| 188 | 205 | |
| 189 | - In Fossil, a developer might write a forum post that later gets | |
| 206 | + This costs you in mental gear-switching when moving from the code | |
| 207 | + repository to the documentation system to the forums to the ticket | |
| 208 | + tracker. | |
| 209 | + | |
| 210 | + More than that, though, a developer might write a forum post that later gets | |
| 190 | 211 | promoted to a wiki article or to an embedded version-controlled |
| 191 | - project document. The developer simply copy-pastes the forum post | |
| 192 | - text into the new document and saves it, not needing to carefully | |
| 212 | + project document. A developer on a Fossil-backed project may simply copy-paste the forum post | |
| 213 | + text into the new document and save it, not needing to carefully | |
| 193 | 214 | check that it still renders properly under the second Markdown |
| 194 | 215 | rendering engine. Similarly, if a user reports a potential bug via |
| 195 | 216 | the forum, the developer can copy interesting pieces of the |
| 196 | 217 | Markdown from the post into a ticket comment, again without |
| 197 | 218 | needing to fiddle with dialect incompatibilities. |
| 198 | 219 | |
| 199 | - But it goes futher. Fossil has a feature for [project-specific | |
| 200 | - extensions](./serverext.wiki), which backs the [SQLite Release | |
| 201 | - Checklist][srckl], for instance. You wouldn’t know by looking at | |
| 202 | - that page that the software backing that page isn’t actually part | |
| 203 | - of Fossil: the extension delivers up just the core of the page, | |
| 204 | - and Fossil’s skining wraps it in a way that lets it inherit all of | |
| 205 | - the per-project skinning customizations. | |
| 206 | - | |
| 207 | - 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), | |
| 220 | + 10. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), | |
| 208 | 221 | through and through. Git-backed lash-ups tend to incorporate |
| 209 | 222 | either proprietary add-ons or proprietary hosting systems that |
| 210 | 223 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 211 | 224 | complete backup (point 2) of the project including its |
| 212 | 225 | idiosyncratic customizations and stand it up elsewhere on |
| 213 | 226 | commodity hardware and software stacks. |
| 214 | 227 | |
| 215 | 228 | [Discord]: https://discord.com/ |
| 229 | +[edoc]: ./embeddeddoc.wiki | |
| 216 | 230 | [Jira]: https://www.atlassian.com/software/jira |
| 217 | 231 | [MediaWiki]: https://www.mediawiki.org/ |
| 218 | 232 | [Sphinx]: https://www.sphinx-doc.org/en/master/ |
| 219 | 233 | [SSO]: https://en.wikipedia.org/wiki/Single_sign-on |
| 220 | 234 | [srckl]: https://www.sqlite.org/src/ext/checklist/top/index |
| 221 | 235 |
| --- www/whyallinone.md | |
| +++ www/whyallinone.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | |
| 15 | > *I don't want forum/web software built into my dvcs.* |
| 16 | > *I don't see how this improves over git.* |
| 17 | |
| 18 | This commenter may hold whatever opinions he wishes, of course. |
| 19 | However, here are a few reasons why bundling other project management |
| 20 | features with the DVCS might be useful for a given project: |
| 21 | |
| 22 | 1. There is single software package to install and manage for the |
| 23 | project website. |
| 24 | The alternative is to select, install, configure, learn about, |
| @@ -26,11 +26,11 @@ | |
| 26 | ticketing, forum, |
| 27 | chat, documentation, and whatever other software packages your project needs. |
| 28 | Less time spent on project administration details means more |
| 29 | time available to spend on the project itself. |
| 30 | |
| 31 | 2. Because of Fossil’s autosync feature, you get a backup of the |
| 32 | wiki, tickets, forum, and so forth simply by cloning the |
| 33 | repository to another machine and using that clone regularly. |
| 34 | Since the typical Fossil usage pattern is to stand the repo up on a |
| 35 | central server and have the developers clone that repository down |
| 36 | to their personal machines, if the server falls over, the last |
| @@ -107,11 +107,11 @@ | |
| 107 | |
| 108 | 5. The forum and chat features of Fossil are disabled by default, and |
| 109 | you can disable the ticket-tracking and wiki features with a quick |
| 110 | configuration change to its [role-based access control |
| 111 | system](./caps/), allowing you to treat Fossil as a more direct |
| 112 | drop-in for Git. When you’re ready to turn these features on, you |
| 113 | can do so with a few mouse clicks. |
| 114 | |
| 115 | Because Fossil is web-native out of the box, if you’ve delegated |
| 116 | these features to outside systems to flesh out Git’s DVCS-only |
| 117 | nature, Fossil can link out to these systems, and they back into |
| @@ -135,86 +135,100 @@ | |
| 135 | Take the first two points above: standing up a Fossil repo backup |
| 136 | on a new server may be as simple as copying the backup to the new |
| 137 | server and [configuring its stock HTTP server to point at the |
| 138 | backup repository via CGI](./server/any/cgi.md). |
| 139 | |
| 140 | Consider: if you had good backups for all of the elements in a |
| 141 | Git + [Jira] + [Discord] + [MediaWiki] + [Sphinx] lash-up, how long |
| 142 | would it take you to stand up a replacement? That lash-up |
| 143 | certianly has more features combined than Fossil alone, but are |
| 144 | they worth the administration and hosting costs they impose? |
| 145 | |
| 146 | Considerations such as these push many into centralized hosting |
| 147 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 148 | just takes you back to point 3 above. |
| 149 | |
| 150 | 8. Hosting all of these elements within a single service gives a |
| 151 | consistent look-and-feel across all aspects of the project. |
| 152 | |
| 153 | This goes deeper than simply skinning independent software |
| 154 | elements, though that’s a big enough problem by itself. If you use |
| 155 | a separate DVCS front end, chat system, forum manager, |
| 156 | documentation system, ticket tracker, and so on, you are likely to |
| 157 | be relegated to simply matching colors and fonts; you might also |
| 158 | be able to add a common logo to the header of all of these |
| 159 | independent pieces. Without heroic levels of local customization, |
| 160 | the pieces won’t look unified, because they weren’t developed that |
| 161 | way. |
| 162 | |
| 163 | The Fossil project not only has a single central development focus |
| 164 | resulting in a unified web UI design, it gives you a common |
| 165 | skinning system for all of its elements so that if you want to |
| 166 | customize its appearance, your improvements affect all elements of |
| 167 | Fossil. |
| 168 | |
| 169 | Or not: there’s a feature in Fossil that lets skin customizations |
| 170 | apply to only *some* Fossil features. The initial impetus behind |
| 171 | this feature was that one of our users wanted Markdown to be |
| 172 | rendered with different indentation in forum posts than in |
| 173 | embedded documentation owing to the inherent differences between |
| 174 | the two presentation modalities. Yet, when a user taking advantage |
| 175 | of this feature wishes to change a UI element common to all Fossil |
| 176 | features — say, to change the font for literal code blocks — they |
| 177 | can still make that sort of global change, the per-feature CSS |
| 178 | inheriting all skin changes it doesn’t explicitly override. |
| 179 | |
| 180 | Speaking of Markdown, unifying all of these features within Fossil |
| 181 | means we have a single Markdown interpreter common to all |
| 182 | elements. If you lash multiple software systems together, even if |
| 183 | they can all agree on Markdown as a common document markup |
| 184 | language — hardly a given, as shown by the MediaWiki and Sphinx |
| 185 | elements in point 7 above — they’re likely to render your text |
| 186 | using different — possibly even incompatibly-different — Markdown |
| 187 | dialects. |
| 188 | |
| 189 | In Fossil, a developer might write a forum post that later gets |
| 190 | promoted to a wiki article or to an embedded version-controlled |
| 191 | project document. The developer simply copy-pastes the forum post |
| 192 | text into the new document and saves it, not needing to carefully |
| 193 | check that it still renders properly under the second Markdown |
| 194 | rendering engine. Similarly, if a user reports a potential bug via |
| 195 | the forum, the developer can copy interesting pieces of the |
| 196 | Markdown from the post into a ticket comment, again without |
| 197 | needing to fiddle with dialect incompatibilities. |
| 198 | |
| 199 | But it goes futher. Fossil has a feature for [project-specific |
| 200 | extensions](./serverext.wiki), which backs the [SQLite Release |
| 201 | Checklist][srckl], for instance. You wouldn’t know by looking at |
| 202 | that page that the software backing that page isn’t actually part |
| 203 | of Fossil: the extension delivers up just the core of the page, |
| 204 | and Fossil’s skining wraps it in a way that lets it inherit all of |
| 205 | the per-project skinning customizations. |
| 206 | |
| 207 | 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), |
| 208 | through and through. Git-backed lash-ups tend to incorporate |
| 209 | either proprietary add-ons or proprietary hosting systems that |
| 210 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 211 | complete backup (point 2) of the project including its |
| 212 | idiosyncratic customizations and stand it up elsewhere on |
| 213 | commodity hardware and software stacks. |
| 214 | |
| 215 | [Discord]: https://discord.com/ |
| 216 | [Jira]: https://www.atlassian.com/software/jira |
| 217 | [MediaWiki]: https://www.mediawiki.org/ |
| 218 | [Sphinx]: https://www.sphinx-doc.org/en/master/ |
| 219 | [SSO]: https://en.wikipedia.org/wiki/Single_sign-on |
| 220 | [srckl]: https://www.sqlite.org/src/ext/checklist/top/index |
| 221 |
| --- www/whyallinone.md | |
| +++ www/whyallinone.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | |
| 15 | > *I don't want forum/web software built into my dvcs.* |
| 16 | > *I don't see how this improves over git.* |
| 17 | |
| 18 | This commenter may hold whatever opinions he wishes, of course. |
| 19 | However, there are many good reasons why bundling other project management |
| 20 | features with the DVCS might be useful for a given project: |
| 21 | |
| 22 | 1. There is single software package to install and manage for the |
| 23 | project website. |
| 24 | The alternative is to select, install, configure, learn about, |
| @@ -26,11 +26,11 @@ | |
| 26 | ticketing, forum, |
| 27 | chat, documentation, and whatever other software packages your project needs. |
| 28 | Less time spent on project administration details means more |
| 29 | time available to spend on the project itself. |
| 30 | |
| 31 | 2. Fossil’s autosync feature gives you an implicit backup of the |
| 32 | wiki, tickets, forum, and so forth simply by cloning the |
| 33 | repository to another machine and using that clone regularly. |
| 34 | Since the typical Fossil usage pattern is to stand the repo up on a |
| 35 | central server and have the developers clone that repository down |
| 36 | to their personal machines, if the server falls over, the last |
| @@ -107,11 +107,11 @@ | |
| 107 | |
| 108 | 5. The forum and chat features of Fossil are disabled by default, and |
| 109 | you can disable the ticket-tracking and wiki features with a quick |
| 110 | configuration change to its [role-based access control |
| 111 | system](./caps/), allowing you to treat Fossil as a more direct |
| 112 | drop-in for Git. When you’re ready to turn these additional features on, you |
| 113 | can do so with a few mouse clicks. |
| 114 | |
| 115 | Because Fossil is web-native out of the box, if you’ve delegated |
| 116 | these features to outside systems to flesh out Git’s DVCS-only |
| 117 | nature, Fossil can link out to these systems, and they back into |
| @@ -135,86 +135,100 @@ | |
| 135 | Take the first two points above: standing up a Fossil repo backup |
| 136 | on a new server may be as simple as copying the backup to the new |
| 137 | server and [configuring its stock HTTP server to point at the |
| 138 | backup repository via CGI](./server/any/cgi.md). |
| 139 | |
| 140 | Consider: If you had good backups for all of the elements in a |
| 141 | Git + [Jira] + [Discord] + [MediaWiki] + [Sphinx] lash-up, how long |
| 142 | would it take you to stand up a replacement? That lash-up |
| 143 | certainly has more features combined than Fossil alone, but are |
| 144 | they worth the administration and hosting costs they impose? |
| 145 | Fossil’s feature set suffices for the SQLite project it was |
| 146 | created to serve, as well as for many others; is your project |
| 147 | sufficiently more complex, such that it *needs* all of those extra |
| 148 | features and their concomitant complexity? |
| 149 | |
| 150 | Considerations such as these push many into centralized hosting |
| 151 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 152 | just takes you back to point 3 above. |
| 153 | |
| 154 | 8. Hosting all of these elements within a single service gives a |
| 155 | consistent look-and-feel across all aspects of the project. |
| 156 | |
| 157 | Skinning independent software packages’ web interfaces to make |
| 158 | them appear unified is more work than skinning everything once, as |
| 159 | in Fossil, and even then, you can’t make independently-developed |
| 160 | software look like it was produced by a single entity without |
| 161 | resorting to heroic levels of customization. If you use a separate |
| 162 | DVCS web front end, chat system, forum manager, documentation |
| 163 | system, ticket tracker, and so on, you are likely to be relegated |
| 164 | to simply matching colors and fonts; you *might* also get the |
| 165 | ability to add a common logo to the header of all of these |
| 166 | independent pieces. The pieces won’t look unified, because they |
| 167 | weren’t developed that way. |
| 168 | |
| 169 | The Fossil project, being a unified software development effort, |
| 170 | not only offers a unified web UI design, it gives you a common |
| 171 | skinning system for all of its elements so that if you want to |
| 172 | customize its appearance, your improvements affect all elements of |
| 173 | Fossil. |
| 174 | |
| 175 | Or not: there’s a feature in Fossil that lets skin customizations |
| 176 | apply to only *some* Fossil features. The initial impetus behind |
| 177 | this feature was that one of our users wanted Markdown to be |
| 178 | rendered with different indentation in forum posts than in |
| 179 | [embedded documentation][edoc] owing to the inherent differences between |
| 180 | the two presentation modalities. |
| 181 | |
| 182 | A user taking advantage of this per-feature CSS capability who |
| 183 | wishes to change a UI element common to all Fossil features — say, |
| 184 | to change the font for literal code blocks — may still make such a |
| 185 | change globally. Opting into this per-feature CSS doesn’t fork all |
| 186 | skinning efforts: UI elements not explicitly reskinned on a |
| 187 | per-feature basis inherit the global skinning. |
| 188 | |
| 189 | But it goes futher. Fossil has a feature for [project-specific |
| 190 | extensions](./serverext.wiki), which backs the [SQLite Release |
| 191 | Checklist][srckl], for instance. You wouldn’t know by looking at |
| 192 | that page that it’s produced by software that isn’t actually part |
| 193 | of Fossil: the extension only delivers the core of the page, |
| 194 | and Fossil’s skining wraps it in a way that lets it inherit all of |
| 195 | the project-level skinning customizations. |
| 196 | |
| 197 | 9. Unifying all of these features within Fossil |
| 198 | means we have a single Markdown interpreter common to all |
| 199 | elements. If you lash multiple software systems together, even if |
| 200 | they can all agree on Markdown as a common document markup |
| 201 | language — hardly a given, as shown by the MediaWiki and Sphinx |
| 202 | elements in point 7 above — they’re likely to render your text |
| 203 | using different — possibly even incompatibly-different — Markdown |
| 204 | dialects. |
| 205 | |
| 206 | This costs you in mental gear-switching when moving from the code |
| 207 | repository to the documentation system to the forums to the ticket |
| 208 | tracker. |
| 209 | |
| 210 | More than that, though, a developer might write a forum post that later gets |
| 211 | promoted to a wiki article or to an embedded version-controlled |
| 212 | project document. A developer on a Fossil-backed project may simply copy-paste the forum post |
| 213 | text into the new document and save it, not needing to carefully |
| 214 | check that it still renders properly under the second Markdown |
| 215 | rendering engine. Similarly, if a user reports a potential bug via |
| 216 | the forum, the developer can copy interesting pieces of the |
| 217 | Markdown from the post into a ticket comment, again without |
| 218 | needing to fiddle with dialect incompatibilities. |
| 219 | |
| 220 | 10. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), |
| 221 | through and through. Git-backed lash-ups tend to incorporate |
| 222 | either proprietary add-ons or proprietary hosting systems that |
| 223 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 224 | complete backup (point 2) of the project including its |
| 225 | idiosyncratic customizations and stand it up elsewhere on |
| 226 | commodity hardware and software stacks. |
| 227 | |
| 228 | [Discord]: https://discord.com/ |
| 229 | [edoc]: ./embeddeddoc.wiki |
| 230 | [Jira]: https://www.atlassian.com/software/jira |
| 231 | [MediaWiki]: https://www.mediawiki.org/ |
| 232 | [Sphinx]: https://www.sphinx-doc.org/en/master/ |
| 233 | [SSO]: https://en.wikipedia.org/wiki/Single_sign-on |
| 234 | [srckl]: https://www.sqlite.org/src/ext/checklist/top/index |
| 235 |