Open Source Concerns

the_Grinch

I work for a state agency and as with most state governments funding is always an issue. Now, we're a bit of a special case as we aren't funded by tax dollars, but funding is still an issue. We're doing some big things and honestly open source software is the reason we can. The concerns that have been creeping into my head at the moment revolves around the setup and continued support of the things we have built. I'm worry if myself or the other member of our team either gets hurt or leave then our unit is up the creek without a paddle. At first I thought I was documenting pretty well, but we ran into an issue and it wasn't until I hit my test box that I saw the step I missed. Some of the newer software we are setting up has been a lot of trial and error. So while we're getting it up and running I question if there was an issue would we remember how to do it again. Any tips or suggestions on how to keep track of things along with making it so I could grab a secretary and say "get this back up asap"? Thanks as always!

ccnxjr

Puppet or Chef
Which centralizes and standardizes your system configuration.
It still requires some discipline, but worth it.
Modern implementations will include some sort of NoSQL database where the configurations are stored, instead of just loose files laying around.

Qord

One of the things I've gotten into is making two sets of documentation, one is everything I think we'd need to redo something I've done, and the other is everything. Literally everything I can take the time to collect, screenshots, docs, screencasts...one big folder full of everything I could collect on the process.

For every server I set up/manage/work-with, I create a folder named after the server. For every specific service on that server, I have a subfolder named after that service. In that there are two folders, short and long. Short is what I think is necessary to redo all the work, long is all the work done. Some of these folders contain multiple subfolders (the jabber server), and others just have a text file or two (the dhcp servers). Either way, the documentation present, organized, and thorough. Naturally, this results in a lot of potentially useless junk in that second piece, which is why having the first piece is so important. However, if I missed something in the first, I'm almost guaranteed to have it in the second.

I also try to make my documentation during the initial setup and config instead of after, as well as update it for changes when I make the changes, not "tomorrow".

wes allen

Sustainability is an issue with any inhouse dev, open source or not. If you find yourself writing a lot of custom scripts or having a lot of code dependencies to get something working, then that is going to be hard to maintain for the long run. Sounds like you are on the right track with the documentation though - the one thing that is always helpful to me, is more then just the code, write up some of the thought process behind the decisions. Like we went with this version because the newer version breaks this other thing. That kind of info makes it way easier to maintain things.

wgroom

Have you thought about an in-house knowledge base? Something employees have access to? A place to build the kind of information you are looking for, something along the lines of what Qord does but keyword searchable?

paul78

I do a bit of playing around for my own interest with various open-source packages and commercial tools. And a lot of it is trial-and-error and experimentation. While it's not for my personal edification and not for commercial or production use like you need, what I have found useful is to use a simple Wiki to track notes and document various items that I would otherwise forget.

Perhaps you could consider using a Wiki as a simple sharable knowledge-base. Since you are using open-source tools - I would recommend MoinMoin - that's what I use. You can find a pre-built appliance here - this is what I use - MoinMoin - Wiki Engine | TurnKey Linux Virtual Appliance Library