Standard list of existing software to examine

I’d like us to have a standard list of software we examine when we want to decide how to model things.

The list is here.

Please comment if you have more items and I’ll add them :slight_smile: also comment if you think some items should be removed.

1 Like

GitHub/GitLab are great, but it’s going to be harder for those of us using stuff like Atlassian BitBucket for projects, even with open source licenses.

Could you elaborare why you think that?
For example which features you have in mind that BitBucket provides that GH/GL do not? :slight_smile:

1 Like

It is more for situations where the other two aren’t the first choice. My entire division is using the Atlassian software, which wasn’t actually my call. I would not have made the same decision were it mine to make, so we need a solution for those using atlassian software, too.

@cambridgeport90, I added bitbucket to the list. However I don’t think anyone else in this community uses it or expressed interest, and I know very little about it. If there are some features it has that are unique to it and you’d like to make sure they make it into the ForgeFed spec, please open a forum topic and write about them, otherwise we may miss them.

does bitbucket have an API - if not, then there is no point in considering it

there is no reason for forge-fed to accommodate proprietary forges without a complete API - it would be impossible to integrate forge-fed into them anyways, unless one assumes either:

  • the forge has a complete read/write API
  • the authors are likely to implement forge-fed due to a feature-request
  • the authors are likely to license the forge freely someday

note that even if the forge has a complete API, those typically require the credentials of each repo maintainer for any write operations and many read operations - so at most, the use of forge-fed would be useful only to those with credentials for that forge (e.g. no one using other forges could send merge request to it, nor comment on tickets) - its not clear how much value there is with such a limited subset of forge-fed functionality - it would reduce to an API wrapper for that specific forge, such as the github CLI client

i have added ‘reclaimid’ to the list

@bill-auger, the list of forges is just for examining their features, to have a wide perspective on the variety of features and their variations in forges. It’s not a list of implementation candidates :slight_smile: so bitbucket not having API is fine


  • lightweight frontend
  • time-tracking
  • reports
  • plugins
  • ruby on rails – not popular enough to be easily developed by community
  • no pull-requests
  • no code review
  • no continuous integration


  • feature-completeness
  • lots of extensions, although many in (pre)alpha state
  • hard to develop by community, poor docs on inner workings
  • not easily extendable
  • hard to deploy and maintain


  • simple and lightweight
  • deployed in no-time
  • no dependencies
  • lack extended code collaboration features
  • unpopular

Not sure how it fits, but its a very cool project I’d like to mention:

It is trending on HN now:

And in an earlier HN thread @emacsen mentioned ForgeFed too (

There is already an issue in their repo: (new user, I can only add 2 links).

1 Like

Arnold -

could you summarize what git-bug is? - off-hand, is assume it
could “fit in” as a potential peer, if someone wrote a forge-fed
bridge for it, or implemented native forge-fed support into it

Bill, I am not using the software, just got interested from what I found on their page.

i was only asking if you could describe what it is that you found
to be interesting, and why you believe that it could be
interesting for forge-fed

I had a look at git-bug the other week, and as the author says on the linked issue, it’s not quite aimed at the same use case as ForgeFed. Its storage format is very particular to the issues-inside-git use case and the git storage format and not instructive for how an AP issue should look.

That said, it has bridges to a couple of forges, proprietary and free software ones, and the lesson to be drawn from that might be that just like how AP has a S2S API and a C2S API, it would make sense for ForgeFed to consider how clients external to a web-based forge should communicate issues and pull/merge requests with the forge (building on AP C2S?). At that point, it would be relevant for people who enjoy using git-bug to implement a bridge for the ForgeFed client API.

1 Like