Confluence Code Quality
Yes, I did spend quite some time playing with things under the hood of Confluence, but I got access to the source code only recently so my opinion might be premature in certain points. This is what I think about the code, based on the portions of codes that I explored so far:
Overall the Java code is easy to read. I can't judge the architecture because I haven't been digging in the code for too long yet, but the bits and pieces that I needed to look at or modify were well formated, easy to read and absorb.
Having said that, I don't understand why I couldn't find one single JavaDoc comment in the source base. Is Atlassian allergic to JavaDocs? It would make my life much easier if things were properly documented in the code. In general the code documentation is lacking or nonexistent. When I needed to write a custom authenticator, it took me much longer to do it than expected, just because the documentation was missing, wasn't detailed enough, or was outdated.
One thing that surprised me a lot was the database schema. I usually try to make the db schema in my applications as tight as possible and I'm not happy unless all the table/column/constraint names follow certain (unified) naming conventions.
The first time I looked into the db after I got my Confluence up and running was "OMG! These people can't even decide on table name conventions". After digging deeper I found other flaws. Just to mention a few:
- when using MySQL, Confluence doesn't create InnoDB tables by default. It happily creates MyISAM tables, unless you configure your db to use InnoDB by default.
- FKs are not used as often as one would expect
- the "users.username" and not "users.id" is used all over the place as a reference to user accounts, which effectively makes username changes next to impossible (Atlassian knows about this problem and promised us to fix it by v2.7)
- lastly - is the db schema documented somewhere at all? I found a messy doc describing JIRA's db schema, but I couldn't find anything similar or better for Confluence.
Atlassian as a Company and its ProcessesThe things I like about Atlassian is that they are trying to be transparent towards its customers. JIRA where anyone can search existing bugs and submit new reports for all of their products is extremely helpful for everyone in the community. There aren't many commercial projects that practice such an openness. Did I mentioned all the tech and biz blogs that Atlassians have?
The other thing that I appreciate a lot is Atlassian's agile release cycle. We are getting new production builds every 2-3 weeks and these builds usually contain fixes for issues that we recently reported. One thing I miss here though, is some kind of roadmap. I don't need a very detailed roadmap, all I'd like to see is a list of all planned releases for the next 6 months, with approximate dates and key features. This would allow me to plan our releases better.
When it comes to support, in general I had a feeling that it wasn't as responsive as I'd like it to be, but we recently heard that Atlassian's about to expand its support team so I have faith that this will improve shortly. Having said that, I recently tried the live chat support option and it worked great, I got my question answered quickly and that helped me resolve some issues I had.
Atlassian got recently wet from the rain of security issues that we, as well as another customer, reported in the last few days and weeks. It didn't take relatively too long and all the issues were fixed in the recently released version 2.5.6.
I had a conversation with Chris Owen from Atlassian, who assured me that Atlassian is taking proactive measures to weed out all the easy to catch security issues from Confluence. In addition to that Atlassian is planning to make some changes to the process of how security issues are being handled. If he keeps his word and these things become reality then I'll be a happy camper :).
Igor - thanks for your fair post. Personally I'm always jazzed when customers write up balanced opinions of us (that's both positive and negative) - as it does help us improve.
Yes - our JavaDoc could certainly be better (we're far from good here).
The database issues are largely due to using Hibernate's schema migration tools, but I agree that InnoDB makes more sense. I'm not sure honestly how hard this is to do via JBDC.
As always, we're aiming to consistently improve. Our hope is that our openness shows a commitment to doing this.
Hani (who I must admit is a good mate) is always sensational - that's what the BileBlog is aiming at. In all, I think we actually got off quite lightly in our latest pasting there (we've had quite a few).
I'm glad you like my post.
I like Confluence and I'm interested in making it even better. Should it be via patch contributions, comments, JIRAs, etc.
I really appreciate the Atlassian's transparency, and I really hope that you will make Confluence even more open to us developers by refactoring some legacy code that is causing problems, publishing better development documentation, best practices and some kind of road map.
I have a question that I don't think you've answered elsewhere, though you have discussed why you selected Confluence. I'm interested in why you don't use the Wiki functionality that's in Sun's Portal Server 7? I realise it came too late for the original launch, but have you evaluated it? Is it seen as too immature for use in production? We're looking to launch a Wiki and I'm curious.
We did check out the Portal Server's wiki functionality as well as JSPWiki, but after a thorough evaluation, we picked Confluence because it better fit our specific needs.
Post a Comment