HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Current happenings in ocProducts

Current happenings in ocProducts Because v10 is taking soooo looong to get traction on for the final hurdle, I thought it would be good for me to write another blog post to give some insight into what's been eating up development time recently.
The long v10 dev process frustrates me more than anyone, and I can't thank our loyal users enough for their patience through it.

So, as most ocPortal users know, ocPortal (soon to be named Composr CMS) is primarily developed by my company, ocProducts, and I've been the lead ocPortal developer over the years.

The business plan has always been to pull ocPortal forward as a result of the work we do for our customers, rather than as a hobby project – and thus to maintain it to a very high quality, but also being free and Open Source.

The fly in the ointment is when my company gets so busy, doing those pure development tasks that don't directly relate to customer projects, can be really hard to fit in. It's meant to be a relatively small amount of work, because the actual features come from the needs of our customers, but v10 is a total product and brand relaunch, and my company generally has been very busy very quickly after a damaging recession. That means a rapid and unplannable staffing regearing has been needed, in the context of a rapidly changing programmer employment market, and a rapidly evolving tech-field. It sure is tough running a complicated business during such turbulent times, it makes programming look easy to me. And, I am determined Composr v10 is going to be a really solid project for the new online age, with very few compromises.

I have honestly been tearing myself apart a bit recently, as people who talk to me may have noticed. I beat myself up about delays, and any bugs, etc, especially when it all gets drawn out.

I have to be a bit vague about any project specifics, I can't talk about particular customers and partners too much, obviously running a company one has to be professional and discreet. Please don't try and publicly guess what the projects may be for this reason ;). It might be of general interest just to get a picture on what happens in web development companies, because day to day challenges don't get talked of a whole lot. If there's one thing I'm personally for it is openness and honesty, because I find it lacking most places I look, and I think it's really important for people to move forward. Not just Open Source, but real openness about how decisions are made too. But openness with discretion where required ;).

One project that tied me up personally for the last few weeks is one particular integration that one of our customers requested quite some time back. The particular thing we were integrating, it turned out they had 170 errors in their documentation or bugs in their systems, that each had to be worked around (I have a list, I can be anal like that). A project that should have taken a few weeks, became a project that took a few months, then needed a few weeks with my expertise to finish. Ouch. But this is extremely common unfortunately because when you do a project you never truly know what problems there may be between A and B.

Another project is one we were asked to take over quite some time back from another company, who has exited the web development market. This was a request based on a referral from a previously satisfied customer. Orphaned projects happen quite a lot – companies may decide that a project is not as lucrative as some other opportunity, or they can't break even any more on their costs (a real issue nowadays for some companies), or they just want to move on for some other reason. We picked the project up and it turned out to be missing all technical documentation, have half a dozen stakeholders with active problems with the system, have a core part of the system depended on proprietary technology that had been discontinued, have load of bugs, and have no basic specification on what the project is meant to do. But it's a business-critical system used by lots of people involved in major institutions. So every day there are a few discussions, people need to be connected together, everyone needs to be beating to the same drum, etc – it can take a lot of time as a manager just to keep things flowing.

It is often the case that things are in the pipeline for quite a while, and maybe they go through, or maybe they don't get all the way to starting (which again is another time absorber, weeks of work specifying things up, then things change). This is part of the big of the trials of running an agency. You need to pursue different things people bring to you, but very often they find the potential customers can't get the investment they need – they needed a specification to know the price and talk to an investor, but the investors may not green-light it (for example, there are dozens of scenarios). To me it's not so much a matter of having to bring in work (although of course any agency has to, but we've been flooded anyway), it's more of a matter of treating people with respect: people want a quote, want to go through detailed discussions, and expect that all to be free and paid off as a part of the project only if the quote is agreed. You have to basically do what people expect and want, but it can eat up a reasonably high percentage of the year when it all gets added up.

Another project we have on is for one of the world's largest companies. We've maintained it for years and it has an absolute tonne of users. Every few months we are asked to extend the system. It's great repeat business but our "no new work" rule we have at the moment can't apply for existing commitments, because of course we have to treat our customers with respect and provide continuity of service.

Another project is a major startup that is turning into a huge success. Continuous development goes on from a fluid team of people, and lots of stakeholder partners. Big new phases are in the planning, and it takes a lot of time to manage or work on. Most days I'm involved in discussions with a few people.

Another project is a re-design and set of new features for a customer we've done little things for for years. We don't only do ocPortal projects (it's probably less than 50% of what we do actually), but when we do do ocPortal projects then I am actively involved in training, quoting, hiring, assessing work, and so on. Actually I do most of that for non-ocPortal projects too, but for ocPortal ones of course I have extra to add, especially when complex core changes are going on.

That's just a few. There are lots of other projects where we do repeat work also, or ongoing amends as feedback that comes in.

In terms of v10 work, constant work for v10 is going on, just not core programming by me right now. We've had developer(s) working replacing 100s of documentation screenshots for a few weeks. It's a big job, but I'm firm that v10 must effectively relaunch us, throwing away any legacy overhead. Having screenshots taken from ocPortal version 2, for the Composr version 10 documentation, isn't good. So we need to work through all these kinds of things.

Hopefully this gives people some insight. We didn't intend to get so busy so late into the v10 development, and the "pipeline" and "repeat business" effects have reduced the effectiveness of our "no new projects" lock-down. But inevitably I'll get freed up again. I'm trying to delay future phases of ongoing projects or structure work to depend less on me. Definitely once v10 is out I intend to decentralise things some more! That's actually a big part of the cleanup: streamlining ocPortal systems, and removing legacy, makes it a whole lot maintainable by other/more people.

Peace out :hippie:

View all


There have been no trackbacks yet