Fossil has always seemed really cool, but I don't know if having everything in one big dependency bundle is actually a good thing. For a variety of reasons, there will never be a consensus on the right issue tracker and wiki for every project (and Fossil's implementation is necessarily quite lightweight and light on capabilities compared to the big guys), so having them all tied together in an integrated whole is probably one reason Fossil as a revision control system didn't take off. It caused bunch of people to select out because they were thinking, "Well, we can't use this tracker or this wiki, because we need X and Y from our tracker/wiki. This system isn't for us."
That said, I'd love to see these features built as add-ons to git; it wouldn't be particularly difficult (no more difficult than developing a ticket tracker or a wiki independent of git). Then again, I'm uncomfortable with the repository dragging in lots of big stuff like screenshots and diagrams and such, which are very common for bug trackers and wikis and less common for code repositories (and something git historically didn't do well, anyway).
Perhaps having a separate git repo for each piece (source, bugs, wiki) and a convention of including links to them inside of special hidden file (like .gitignore) would be the right thing. But, then we don't have the issues and docs following the code around very closely, which gives up some of the positives.
But, out of the box, Fossil is a really nice looking system. If I weren't working with other people who already know git (which describes almost everyone everywhere), I'd probably give it a go. But, I am, so I won't.
I hear what you're saying, but I don't think someone evaluating Fossil should say things like, "We've always been a Bugzilla/MediaWiki/whatever shop, so we won't use tools that don't integrate with that." Instead, they should evaluate whether Fossil's version of those features provides what they need.
Specifically regarding the ticket tracker, someone evaluating Fossil should realize that it is really flexible:
If you don't like what Fossil's ticket system does out of the box, you can probably make it do what you need with a small amount of customization.
I don't mean to be rude or cast aspersions on you, but there's a lot of FUD like this surrounding Fossil. People look at multicolumn feature lists and see this one weird feature in one of the non-Fossil columns that has a check where Fossil doesn't and write Fossil off because they think they might need that feature. This kind of thinking is why there are so many 4x4 SUVs in the grocery store parking lot.
The simple fact is that there are a whole lot more relatively small software development teams than there are huge teams that really need a large fraction of the features in the large competing software packages.
Realize that I'm saying this about a DVCS that was designed to fit the needs of SQLite.org. If your team, code base, and community isn't larger than that of SQLite.org, it's "small" in this context, and can probably work happily within Fossil's limitations. Just as you won't be putting your Jeep Grand Cherokee in 4-Lo to get out of the parking lot, you probably don't actually need everything that, say, Bugzilla provides over Fossil's ticketing system.
Now, if you're comparing Fossil ticketing to Redmine + the Scrum dashboard plugin, and your project management is currently based on that workflow, that's a horse of a different color. But then, there's nothing preventing you from ignoring Fossil's ticketing feature and continuing to use your existing project management system.
I agree with you, but I think a whole lot of people working with small teams are tied up in the Github workflow, and the ancillary third party tools around it, and would find migrating a chore not worth the effort (and they'd lose a few things, as well). I'd like to be less tied to proprietary stuff, but the ship seems to have sailed on that, at least for now, until Github turns evil or starts to suck.
That said, I'd love to see these features built as add-ons to git; it wouldn't be particularly difficult (no more difficult than developing a ticket tracker or a wiki independent of git). Then again, I'm uncomfortable with the repository dragging in lots of big stuff like screenshots and diagrams and such, which are very common for bug trackers and wikis and less common for code repositories (and something git historically didn't do well, anyway).
Perhaps having a separate git repo for each piece (source, bugs, wiki) and a convention of including links to them inside of special hidden file (like .gitignore) would be the right thing. But, then we don't have the issues and docs following the code around very closely, which gives up some of the positives.
But, out of the box, Fossil is a really nice looking system. If I weren't working with other people who already know git (which describes almost everyone everywhere), I'd probably give it a go. But, I am, so I won't.