Our team (40 people) is currently using Confluence as a knowledge base repository. There are many problems with confluence - formatting text is limited; can't paste images in the text; editing bugs; etc.

I have the idea to use something else - have a folder somewhere dedicated to documents. Anyone from the team can put files there, edit files, create folders, etc. Have also web-access with a search engine, and we have everything we want.

I realize we won't be able to track changes, but I don't think it is that important for us.

For second stage I think of something a little more sophisticated: Have a bot mail-user that whenever it receives e-mail, it stores it in said folder. That will make things even easier - since a lot of the information is in e-mails, all I need to do is Cc bot-mail-user, and I'm done.

So my question is: Is this a good/bad idea?

closed as not constructive by Andrew Clear, Bill the Lizard, Brian Carlton, Pawel Brodzinski, Mark C. Wallace Nov 14 '12 at 12:01

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Ae you using the latest Confluence's version? We're using it and - although not perfect - isn't that buggy as you mention. You might be quite confident about your team to dare to build up from the scratch a tool to surpass a widely known software. Just didn't add it as a proper answer as I'm not quite sure this question fits a 'Q&A' format, as there's no proper 'right or wrong' answer, right? – Tiago Cardoso Sep 10 '12 at 12:59
  • 1
    @TiagoCardoso It's a borderline polling question, but I think there's enough PM/framework information to make it a worthwhile question. It could probably use some editing to make it better, but I think the underlying question is worth improving rather than voting to close. YMMV. – Todd A. Jacobs Sep 10 '12 at 13:30
  • 1
    Exactly @CodeGnome, for this reason I raised the question but didn't vote to close. – Tiago Cardoso Sep 10 '12 at 13:39
  • Thanks for rephrasing the question. However, now it sounds obvious that it is not a good idea: Custom in-house workflow? Why would anyone write it instead of using an off-the-shelf solution? But what I have in mind is not a custom in-house workflow. It is just intranet search engine. There are dozens of vendors and free-software projects that do exactly that. – ModdyFire Sep 11 '12 at 12:43

Team Tools

Team tools should be determined by the project's needs (including regulatory compliance requirements), constrained by the budget and labor costs to create and maintain it, and ultimately selected from the field of choices by the team members that will be using it on a daily basis.

"Thou shalt use work-flow X!" is rarely met with enthusiasm, and unless you have a background is designing IT controls, you may have a hard time actually enforcing the use of your top-down tool-chain. Organic, bottom-up tool-chaining is generally a closer fit for the team's current work-flow, and documenting what people actually do (rather than what you wish they would do) automatically results in higher compliance levels.

Alternatives to Completely Rolling Your Own

Even if you decide to bypass commercial or widely-used tools, there are work-flows that don't require quite so much "winging it" on your part. For example:

  1. Don't use carbon-copy (CC) addresses for team communications. If tracking team emails is important, use a mailing list or web-based forum. Google Apps provides both types of functionality, but you also have a wide variety of alternatives such as Mailman, Majordomo, ezmlm, and whatever group mail features MS Exchange has sprouted for its current "pay to play" upgrade cycle.

  2. Even if you bypass enterprise source control or full-fledged document management systems for documents, you still have many choices other than a shared-folder dumping ground. Some examples include:

    • Automatic versioning with Git, Apache, and WebDAV.
    • Versioning and edit tracking with Google Docs or LibreOffice.
    • Use Markdown and Pandoc to put documents under plain-text version control.
    • Use AsciiDoc to put complex documents under plain-text version control.
    • Use a wiki that versions binary blobs or attachments (e.g. GitHub wiki pages) so that you can attach some context to your files.

Consequences of Rolling Your Own

If you use an enterprise-class tool, or at the very least a commonly-used solution, then you can expect a high bus-factor for its use and maintenance. Custom, in-house solutions must be maintained in-house, and are more likely than not to become both unmaintained and unmaintainable over time--especially if the care and feeding of the system is not a formal part of someone's job, nor part of the job description of the person that will eventually replace him.

In addition, in-house tools often require written documentation on how they were setup, how to fix common issues with the tool chain, and written procedures about how to use the tools in accordance with the team's work-flow. As a worst-case example, you will need to clearly proceduralize naming conventions and "who's got the file" processes for managing serial or concurrent access to team documents in a shared folder. If you think this is trivial to do, or not really necessary in a small team, then I applaud your sense of adventure in going where angels fear to tread.

That doesn't mean in-house solutions are bad. Sometimes, they fit the work-flow better than COTS solutions. However, they are not free: there is always a labor cost to design and maintain them, and ongoing process overhead that will vary based on the work-flow and tool-chain, and the tools may represent a form of technical debt that will need to eventually be paid off before the TCO exceeds any up-front cost savings you may (or may not) receive.

The Best Solution of All

The best solution of all is to allow your team to self-organize around a set of requirements. Build a user story around the requirements, and then let the team figure out what tools they need and how to adapt the tool and work-flow to fit one another. As a rough example:

As a team member,
I want to be able to search all project-related emails for a six-month period
so that I can find free-form project-related information using complex search queries.

Focus on who and what, rather than how. Make this user story a priority for the project, and then let the team figure it out. Regardless of the constraints in time, budget, or functionality, you will generally get better results with this approach than with infrastructure-by-fiat.


  • 1
    True! This is what I want, and I should focus on the need rather than the solution – ModdyFire Sep 14 '12 at 21:55

We were using google docs for our internal documentation. You can set user rights, create folders, search in documents, follow versions, compare versions and you can be notified about changes like updates, comments etc.

So my question is: Is this a good/bad idea?

I wouldn't do that. The maintenance costs of self-made tools are too high. You'll need at least one full-time employee to do user support, maintenance, and new feature development.

Here is an example. My old company bought a tool similar to SAP, because the management wasn't satisfied with the tool before this SAP like one. It took us about 2 years to migrate to the new tool properly, and there is a guy who is still doing the user support (the whole thing started in 2006, and it didn't take that long because he wasn't good enough - he was actually a really good developer, but not smart enough to decline the job offer).

If you need something really minimalistic, just set up a samba share and grep for the content. I think this is the easiest and most simple way to do it.


The thing you need to ask yourself is what your goal is. If your goal is to build software, for instance, do you have the time and resources to put into maintaining a solution that you put together internally?

I've been in situations before where solutions that we put together for managing our projects ended up taking a lot of time to maintain, and it's easy to have your time become dedicated to something that is secondary to your business goals.

If you can find an out-of-the-box solution that you can tailor to, that would be best. Otherwise, you may find that trying to make something fit you perfectly may involve a lot of work you didn't consider.

  • You are right, of course, but I'm not sure my suggestion is more work than deploying an out-of-the-box solution. – ModdyFire Sep 10 '12 at 8:51
  • It always seems like that, doesn't it. Until you do it and then later on right when you need all hands working on the project, your duct-taped solution breaks and you need someone to fix it. If you're building a house, don't be in the business of also building hammers. You won't build that great a hammer, and you'll end up spending all your time tweaking the design of the hammer instead of building the house. In my experience, go with the out-of-the-box solution. Let those guys build the hammer; that's their job, not yours. :) – jmort253 Sep 10 '12 at 14:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.