Should we join forces with TopAnswers?

Yesterday I learned about TopAnswers (link is to their meta), another Q&A site built by people recently unhappy with SE. Their site is in the early stages, but:

  • Their goals align with ours. (One of their developers visited our Discord room on Friday where we discussed goals a little more.)
  • They are a software platform and a hosted network open to more communities joining.
  • They have a sane code of conduct.
  • They are up and running, albeit in early stages.

I get the impression from looking around that they haven’t yet tackled some of the questions we’ve been pondering, like answer scores. I don’t know to what extent they’ve considered these questions and come to different answers, and to what extent they just haven’t gotten there yet or are taking “defaults”. (They have reputation, for example, though I don’t know how it’s computed.)

Their front-end design is in early stages, particularly with respect to discoverability and accessibility. They’ve also made some nice decisions, including having “blog post” as a post type (blog posts mix with questions but don’t accept answers) and chat integration (in a pane right next to the question list or an individual question).

They are using a different tech stack than what we’re talking about (though we all agree on Postgres).

So yes there are differences, and we might discover some fundamental incompatibility when we look more closely, but I really think it’s worth us taking a look at what they’re doing and encouraging them to take a look at what we’re doing. If we’re largely compatible, I think it would be a greater service to all involved if we could converge on one project. This means flexibility on both sides and we haven’t yet had more than that one Discord chat with one of them, but can we take a look, with an eye toward engaging them in a conversation about coming together?


I immediately had the same thoughts when I found out about it. It is definitely great that they have something up and running, and it would not do us any harm to advertise them as a solution right now.

There is a benefit with them being on postgres, regardless of whether we join with them or not. We could develop targeting their database as a backend. After all, it seems to me that they are an army of DBAs, they probably know very well what they are doing there.

On the other hand, their frontend does not look very nice, no offense. I’m pretty confident in saying that PHP wont scale to the levels we are looking for, so I think we should continue our efforts on the core project.



  • Goals
  • Code of Conduct
  • Up and Running
  • PHP - I’ll explain


  • Front end needs a lot of work
  • Methodical Development
  • PHP

First PHP:

I am a PHP programmer (as well as Python and some other things). PHP can scale quite well. I know not everyone will agree with that - hey, we can’t even all agree on spaces (right) vs. tabs (wrong) :slight_smile: So for me, PHP is a definite plus, as I would be able to participate far more in the server-side development than C#.

That being said, we seem to have already attracted a decent core of developers sufficiently familiar with C#/ASP.NET that I am reluctant to switch again, unless we have a really good core code in place to build upon.

Code Structure/Quality

I have not looked at the TopAnswers code (I know it is open source, but I don’t know if/how it can be accessed right now - I haven’t looked). But I suspect based on the relatively limited current capabilities of TopAnswers, and especially the relatively basic front end, that the code has a long way to go before it approaches the level of overall complexity that we currently envision for Codidact MVP (voting algorithms, moderator tools, etc.).

I also get the sense, which could be totally wrong, that they have not put the same level of methodical development (e.g., coding guidelines) that we have. That being said, the typical small projects that I work on don’t have those guidelines either - but those projects are typically between 1 (just me) and 4 developers, while Codidact already has a good size team and will likely grow quite a bit over the next few months. The Team & Tech Leads have both put a lot of work into building a group that will treat this as a truly professional project in every respect except money.

That being said, our goals align. We all want the same thing. We all want to have software that supports communities. Etc. So it does make sense to work together as much as we reasonably can.


As far as PostgreSQL, it is a definite plus that we agree on that piece of the puzzle. However, I suspect our schema will differ (there are a lot of ways to build a database), so if we either start with TopAnswers and move to Codidact when ready or if we don’t start with TopAnswers but want to bring in their existing community’s data when Codidact is ready, we will need to do some data conversion to make it all work. But working as friends that will be a lot easier than pulling data from SE as competitors.


At this point, we quite literally have nothing to lose, so I say we should invite them over to discuss the idea.


As @ozewski points out, we have very little to lose; except perhaps a bit of time figuring out if and how we can integrate. While their presentation may not be what we currently have in mind, it’s something, and that is way better than nothing.

Do you have a particular outcome in mind for the discussion, @cellio, both as OP of this topic and Docs lead? Objectives? Or are you thinking of a general, open-ended chat? Would them folding into us be acceptable to both, or vice-versa- would we collectively endorse shelving Codidact and all jumping in line over there? Or separate-but-parallel frontend development around a shared set of schemas? Or a much looser arrangement entirely? My point is, it would be useful to have in mind what are looking for and what we can offer from a collaboration.

It would be great to have @Marc.2377 and @ArtOfCode as Tech and Team leads opine here too.

This seems like a good opportunity to come together and be stronger for it.


Collaboration is always worthwhile; that said, I think we may end up building different products, and I think we should.

On the surface, TopAnswers is doing the same thing we’re trying to do here, but going through the Q&A site itself, it feels like a different approach to Q&A somehow. I’m not entirely sure how at the moment, but one of the big reasons I’m here is because I like the way SE does things for the most part, I’m just not a fan of the company. The vision I have of Codidact is a similar approach to SE - with changes to make things (both product and community) better, of course, but fundamentally pretty similar. TopAnswers feels like it’s taking the idea of Q&A and going “how else could we do this”, whereas I’ve been working here along the lines of “how can we take what SE does and make it better?”

That said, I absolutely would like to see collaboration between our two teams. There’s potentially significant value to be had in working together - that could potentially result in legal cooperation, content sharing, site integrations, up to and including offloading certain features to each other: both sites could offer the sum of both sites’ features, and simply redirect users to the correct place depending on what they’re looking for.


I cannot agree with @ArtOfCode more. Even if we don’t merge, an open collaboration may be beneficial.


That’s interesting, because I’ve been feeling that Codidact started out as “let’s do SE better than SE” and has been heading toward “let’s rethink how Q&A should be done at all; be bold”. What do you see as TopAnswers’s major divergences from the SE baseline?


For now I’m starting a conversation here, because I thought it would be rude to just go over to TopAnswers and say “hey, we have this similar idea; let’s join forces” without checking here first. We have what I understand to be a strong team of developers (and maybe larger than theirs); does it make sense, for example, for us to build our own front end or to help them improve theirs? Can we talk with them about DB support for features we’d like to build later? If, later, they don’t want those features, then we fork; if we and they can agree that we want them, we add them there.

I’d like to build a fantastic Q&A site. I also want a working Q&A site soon, because I have at least one community that is currently dying on SE. I’ve always been a fan of iterative development, more agile and less waterfall – figure out the things we need to know now to proceed, things that would be harder to change later, and don’t worry so much about finer details before we have something running. (I have the impression my approach might be out of alignment with some of y’all.)

I’d like us to approach TopAnswers with the proposition that we have a team of people who want something better and are willing to contribute to their platform if they agree on (whatever key points we’re concerned about that they don’t currently demonstrate). And then we’d have a conversation about those tradeoffs and what capabilities are essential, much like Codidact did starting several weeks ago but this time in the context of an existing system. If they think we’re too demanding or we think they’re too rigid, we might still end up with two projects – though if we can share some underlying infrastructure we still win.

So, Codidact contributors, can we have that conversation? Or are enough of y’all only interested in starting from scratch with Codidact and you wouldn’t be interested in working on the TopAnswers project?


If you have a community in mind that would be an easy first “sale”, please consider saying who it is or at least describing what they need. It’s a lot easier to find the balance between “minimum” and “viable” when you have the needs of real users in mind.


I’m talking about Writing. We haven’t broached this on meta yet (and I’m not sure if SE would suppress it anyway), but the site has no active moderators (and only one inactive one), has lost several top users, and is already seeing quality degradation. Some of us have been talking behind the scenes about how to prevent our community from falling apart while we wait for another Q&A platform to be ready. (It’s tragic: we finally got SE to remove that “beta” label after close to nine years and were doing great, and then this happened.)


To an extent, yes - Codidact definitely started as “SE but better” and has moved more towards “Q&A but better”; that said, I think we’re still generally in agreement that SE did it reasonably well and we can take a decent lead from that, while making improvements as we go.

The major thing that I see TopAnswers doing differently is the choice to put chat right alongside Q&A. That brings a different feel to the experience - rather than it being Q&A with chat as a third place, it’s “Q-and-A-and-chat”, which is not necessarily what we want. It feels to me as if it’s treating questions and answers as a more lightweight type than SE does, whereas I think posts should be treated as the primary type rather than just part of the whole. We’ve had some good ideas here on how to integrate discussion into the model rather than just supergluing chat on top of Q&A, which I don’t think is optimal.

Continuing that theme, I’m finding TopAnswers to be a mix of old-reddit/HackerNews-esque feeling. Both of those sites have been fundamental in the development of the Internet at large, of course, but… I think we (both us here and “we” in general) can do much better than that type of experience these days.

Let me reiterate what I said in my previous post: I’m absolutely interested in working with the folks developing TopAnswers. It’s just not the type of product I envision Codidact to be, which is why I think we should develop separate products with co-operation and integration.


I’d rather have the chat be collapsible, and collapsed on the question list. Did you notice that for an individual question, the chat is not the general chat but one for that question? And that clicking “comment” under a post creates a chat message? That seems similar to the ideas we’ve been discussing for feedback/comments/discussions – there, but not in the way of reading the question and answers.

What things can we reasonably work together on while building separate systems? If we were to approach them, what could we propose?

Content sharing would be the big one for me. I’d like to see the ability to have related content in one system show up in the other in appropriate places - search in particular, so that when you’re looking for an answer to something you get double the pool - but could easily be other places too. That could quite easily just be a link to where the content resides on the other site, but could also be a copy of the content (though that does introduce issues with replication and merging).

From a technical standpoint, that means both teams building APIs for access to content - that could be a public API, but it could also be a keyed or signed-authenticated private API for the sites to call each other to sync content. There are a number of technical discussions to be had around how that’s implemented, both within each team and cross-team.


I have nothing to say about collaboration in general.

However, let me quickly chime in about the “let’s just use their thing for now” idea that’s in the room here:
The quality of their UI is a big issue.
The biggest amount of visitors will be “standard users”.
For a standard user, if the UI is 90% worse, they think the whole app is 90% worse.
A 8/10 UI for 2/10 functionality is gonna do better with standard users than a 2/10 UI for 8/10 functionality.

I can see them finding an answer via search, but quickly leaving again because of the UI. Somebody correct me if I’m wrong, but that’s basically telling google etc. “They opened the website, but came back quickly, so it wasn’t what they were searching” - which would ruin Codidact’s SEO scores.

IMHO, whatever we start out with should be “solid” concerning graphic design and UX.


One thing I was wondering was whether we have people here who could make that UI a lot better (I have definite issues with it!), and whether TopAnswers would accept that help.


IMHO this should be one of the big focuses. For many reasons, not the least of which being that an API means any diversion in design or implementation - not just now but at any point in the future would be mitigated with this feature.

If we were coming from SE with an open sourced codebase and full API, life for us would be much easier right now. Yes, we have the DB dumps, but we’re doing a new database design and writing all backend and front-end code from scratch (at least mostly).

APIs for content access helps both Codidact and TopAnswers now, and anyone and everyone in the future.

1 Like

To what extent do those APIs depend on a shared DB schema? Do we need to negotiate a schema between us and them, at least partially? We might not need to work out every last column of every last table, but we need to agree on the major moving pieces, right? You can build an API around any schema, but in practice APIs tend to reflect the underlying structure.

1 Like

Not particularly. We could have different schema if we wanted to; the APIs would share data either in an agreed format (in which case we’d pre-process the data from the database to the API return value), or in system-native format (in which case we’d post-process an API return value to put it in the database). I think the idea of a “Post” is enough of an agreed major piece.


APIs by their nature hide most of the gory details of underlying schemas. That has a lot of advantages including the ability to connect systems with different schemas, different databases etc. and the ability to change the database or schema of a system while keeping the external API interface the same.

In other words APIs don’t depend on schemas being compatible, they help make otherwise incompatible systems compatible with each other.

1 Like