Rojo is Onomojo’s Ruby on Rails Content Management System. You can find it here:

http://github.com/onomojo/rojo

Today we made some changes to make the initial setup of a Rojo instance easier. The steps to setup a new Rojo instance are clearly detailed in the README. This should help eliminate most of the problems new users were encountering when trying to setup Rojo from scratch. Please let us know if you have any comments or suggestions for improving the setup process.

In the next few weeks, we will be releasing the plugins that we’ve developed for Rojo including a blog, video gallery, photo gallery, and more so stay tuned.

We’ve been working on this part time for a while now and I finally decided to just go ahead and release it. Its far from perfect and isn’t what I originally envisioned but it does work and we do use it on a number of sites. Its fairly stable and we have a handful of plugins that I’ll be releasing in the next week or two.

The 2 main motivations for Rojo came from the lacking diversity in Ruby on Rails content management systems. There are a few and some work well but I wasn’t happy with the learning curve with the ones I explored when we initially started this project. It seemed to me that every time I embraced a CMS the CMS ended up determining how I had to write my application. Its simply impossible to craft a CMS that enforces a strict data and programming interface that works for every situation. I didn’t want a content management system that forced me to write my tables one way or another or forced me to communicate with the CMS in certain ways. In short, I really just wanted a simple core that I could easily extend in any way I needed without having to conform to any standard imposed by the CMS.

You can check out the Rojo code here: http://github.com/onomojo/rojo

I’ve been planning out a content management system in Ruby on Rails for a while now and will be releasing a beta version in the next few weeks. I’m calling the project Rojo. There are quite a few CMSs out there for PHP already and they’re quite mature at this point but the ones I’ve seen for Rails are pretty pathetic to say the least. They’re all really limited in functionality and lack modularity so they’re not always the easiest to extend.

My company, Onomojo, does a decent amount of Ruby on Rails development and have been working on building a solid CMS that’s modular, easily extended, and easily customized. The project itself is coming along nicely. I’ve taken concepts that I like from different content management systems that I’ve used over the past decade and combined them in a way that helps minimize the effort involved in developing Rails sites for our clients. I’m pretty excited about it and I’ll be releasing the core code and the plugin code to the public after we get a few pieces developed so stay tuned for more on Rojo.

I have initiated and promoted the use of wiki software in the two most recent companies I’ve worked for. I will explain my experiences with starting a wiki withing these two different working environments: a large corporate and a mid-sized company.

While working for a large company I realized there was some fundamental problems in the flow of information among our team. Not only our team but the entire project the company was working on. The project was a large military integration project that was struggling to get off its feet after the company won the bid from for it. My team was 10-15 programmers of varying skills. No one talked to each other about work and the people who did know what was going on kept it to themselves because it gave them a political edge over everyone else. Its extremely difficult for everyone to row the boat in the same direction if we aren’t communicating. I setup a wiki to solve the problem.

I was the only one who used it at first but once I had amassed a small amount of information on the wiki, other people started looking more into it. Some of my team didn’t want to use the wiki because they felt it was politically motivated or had their own motives. This environment wasn’t healthy for getting anything accomplished and was mostly just a part of the nature of large government programming contracts. The wiki wasn’t embraced by everyone but those who used it found it useful. I eventually left this miserable project for better opportunities. Fortunately, I left at the right time because no more than 2 months after I left the entire team was either laid off or reassigned. This was not a successful use of a wiki.

The second environment I installed a wiki was for a mid-sized sales driven company. Their main source of information was some random CMS install that was a pain to edit or add things to. It was used mostly by sales agents but really everyone except programmers (we have our own secret wiki). I installed a wiki to replace the CMS. The wiki was immediately put to use by moving everything from the CMS to it. People have continually added to the wiki and made their own pages and sub pages for different departments and so on. Its now grown into something extremely useful that’s used throughout the day by the entire company (minus the programmers). I’m very happy with how its being used especially since these are non-technical people using it and they’ve done so much with it so far. I didn’t need to coax anyone to use it and I didn’t need to play any political games to show people it was a useful tool. There was a need in the company to more easily share information and the wiki filled it.

I attribute the success of the second wiki to a few things:

• lots of information already existed and it needed a better way of accessing it
• a graphical editor that resembles a word processor
• instituted from the top (management) down rather than the bottom (me) up

I’d be interested in hearing from other people with experiences setting up a wiki in their workplace so please comment if you’ve done so.