Skip to Content

Stuff that’s been on our minds...

Karmabunny Blog

Web Tales, Episode 3: decision time on our CMS (content management system).

Posted in Podcast

Listen to Stitcher

Web Tales: web design & development, a small agency perspective podcast

This week on Episode 3:

In this special episode we talk strategically and ethically about the CMS solutions we offer our clients. We shortly have a big decision to make as we discuss the pros and cons of our long term in-house CMS (SproutCMS) versus the many good 3rd party and open source systems available, including Wordpress, Craft CMS, Expression Engine, Concrete 5 and SilverStripe.

Topics include

  • Why are we having this discussion?
  • Why did we build our own CMS in the first place?
  • Is our position defendable in this day and age?
  • Do we throw out a very mature and trusted code base and just turn to a mature open source or licensed product?
  • Do we fork a new version and make it open source given how much work is in the code base?

Note that this is in no way a review of these 3rd party CMS offerings, rather it is a discussion of how they might fit within Karmabunny's client offerings in comparison with our existing in-house CMS.

Articles referenced in this podcast:
Why Use a Custom Content Management System (CMS)
Never Fall for a Custom CMS. Ever.

Content Management Systems referenced in this podcast:
Expression Engine
Craft CMS
Silver Stripe

The Main Chat - our content management dilemma

Darren: OK. This is a bit of a special podcast where we talk about a topic that's a bit relevant to us. Which is what Karmabunny offers to our clients in the way of content management. The players in this conversation will be myself Darren and go round the room.

Jamie: Jamie

Benno: Hi I'm Benno.

Darren: Benno's new by the way, it's very exciting to have Benno here. he will appear on probably more podcasts. Hi Benno, how's it going?

Benno: Good.

Josh: I'm Josh.

Darren: You're all kind of like what exactly? Kind of programmer types aren't you really?

Josh: Yeah.

Jamie: We're all code monkeys here.

Darren: All right, let's push on OK. This is going to be a very specific discussion. This is a bit of a special podcast that we might try and do every now and again. It’s a behind closed doors type of discussion. Where we actually talk about Karmabunny's strategic decisions. Some of the big decisions that we have to make and this is a forum for us to really nod it out. It's pretty honest and I want to be transparent, I think anyone listening to this, they can really get in on it. Have a think about what they would do if they were in our shoes. Because it's an interesting topic I think one that maybe a lot of small agencies are either facing or have faced at some point or other. Some may never have faced it because they went on a different path.

Let’s just talk about it. Basically what I want to talk about is our current position in terms of content management and offerings we currently have for our clients. I suppose this was triggered a little bit from an article I read. First of all, let’s just tell everyone what our current state is. What we offer our client. Basically we have our own CMS sprout it’s called. We’ve offered that for something like I guess well 10 years I suppose 11 years. The current iteration is about seven years old or something seven or eight years old. It’s a great little CMS. It’s very stable code based we’ve built everything from really simple sites to massively complex sites so we know it very well. Basically it’s come to the point where I feel it needs another major iteration done. There’s things that I want to change about it. It occurred to me, is that the best thing for us to do. From a racehorse’s standpoint right now, spend a bunch of time and money on doing that or should we be turning. Making a decision right now to go with some of the ... I know very good CMS/frameworks that are out there in the world and committing to one of those.

I suppose a lot of this was driven by an article that I read which was really super super negative about ever having your own CMS. Basically telling clients you should never choose proprietor CMS each should always be an existing product that’s out there in the wilderness already like a WordPress or equivalent. That anybody who tries to sell you their own proprietor CMS is basically morally bankrupt. I think lets maybe address the points in that article first. Is anyone [Inaudible 00:03:45] to say?

Male: We’re going to read code that’s written by someone at some point. A proprietary CMS, even if you’re buying off the shelf CMS of some description instead of making one yourself it’s still built by someone.

Darren: The code base it’s completely open and transparent. They can take it to another developer who may well had experience with that code base.

Male: Yeah, especially when you start reaching to open source stuff because there’s public documentation, public code availability.

Darren: Yeah, but this addresses one of the main issues. One of his main points in this article is if you commit to a propriety CMS no one can help you but them. So if they get hit by a bus, if you don’t want to work with them anymore, if you take that product to another developer they can’t work with them. What's our answer to that?

Male: I think it’s worth noting as well just before we answer that there’s a lot of these articles. If you actually look and a lot of cases of people that are really pushing the negative points. Saying that this is a bad thing and lot of the time it’s actually agencies that are trying to push WordPress and things on their clients.


Male: Of course, everyone has an agenda. I have no doubt about that.

Male: It’s a very very biased thing to try and research.

Male: We have an agenda. We have our own CMS, so we’re coming up with a response that suits us out of the story as well. I just want us to really try and forget agendas for the moment and go seriously how can we answer that. How can we answer that? How can we answer the fact that if one of our clients doesn’t want to work with us anymore. Which fortunately for us doesn’t really happen very often but if it did, where would they go to get that website code base worked on? What would they do, what are our answers to that?

Male: Well it hangs a little bit on what the client is. Some of our clients have massive complicated almost application level modules that we’ve built for the CMS. In that case, it doesn’t matter what the CMS of the framework was. The maintenance there , it’s all in the customs stuff, the core if we had it based on built in WordPress or built in expression engine or built it straight with a framework, it still 10 times more custom code than the base code. In that case if they stop working with us, it comes down to either rewrite or maintain.

Male: It’s possibly something that’s going for us in particular we work so closely with clients. It’s very rare that by the time we finish a site it’s just the base code. We customise things all the time.

Male: I think it hasn’t always been a bit of a landmark of our projects. That we are quite willing to go in and find out specifically what your needs are, your workflow, your objectives. We’re not afraid to custom code. I wonder about and I don’t know this, I guess developers who commit to using something like say WordPress do they truly do that or do they just try and crowbar into using a plugin that they know about. That's an events plugin or a member’s management plugin that they've used before. I wonder what that dialogue is like with the client. I certainly don’t want to accuse any WordPress developers doing that. I imagine you probably couldn’t help but do that sometimes.

Male: I don’t care what your business practise is or what you would ideally have it be. This is how the system works so you have to ideally use it.

Male: I used to work with a lot of WordPress developers alongside should I say in England. That was generally the approach, it’s not what do you need. It’s what you'll roughly need and I’ll find the closest matching plugin and install it for you for a fee.

Male: Let’s just assume then that we do have some sites that in the end it doesn’t really matter. In the end its going to be so customised that doesn’t matter if we used WordPress or Craft CMS or Expression Engine or our own Sprout. It’s going to be a complicated handover to another developer regardless.

Male: There’s a bit of a difficulty there because you might say “Oh we used this for one client because we know they're going to be simple, or we used this for another client because we really like working with them but we know it’s going to be complicated”. There’s a difficulty there that you've got to be at a predetermined if they're going to be complicated.

Male: Sometimes you don’t really know until...

Male: Because often when you start and it’s only that two years have passed then calling you up wanting extra stuff. That changes from a simple website with a couple of contact phones into this complicated beast with a booking engine and sms sending and who knows what else.

Male: Yeah OK. That is an answer then for the more custom projects. I feel a legitimate response is that if you want us to develop something that’s really custom and bespoke to your needs, then in the end it doesn’t really matter what framework we’re using. It’s going to be a pretty complex handover to another programmer. Maybe the best thing that we can do is just provide as good a documentation as we can regardless of what we use. What about a simpler CMS, what about a pretty much off the shelf brochure style site. Maybe it’s got an image gallery or something but nothing too complex. Maybe some enquiry forms are we in a position where we should be morally comfortable using Sprout when we could use a simpler CMS that has more transparent documentation any programmer could take over from us. How do we answer that in that scenario?

Male: Well there's things to consider there, I mean that wouldn’t on the first imply that we may end up working with two different CMSes for the various projects.

Male: Of course that would be a learning curve or extra effort for us. Because we’re so used to using our own framework.

Male: Then also I mean one thing.

Male: That’s not the client’s fault, that's not their problem that's our problem.

Male: I know that's true and I suppose that the next point I was going to make falls in that bracket as well which is security. Our own code base, we know it’s solid, we know it’s going to be good. We can reassure the client that that’s how it’s going to be. Whereas if we use something that’s commonly targeted like some of the more [Inaudible 00:10:10] CMSes out there. We can’t guarantee to the client that that’s code is going to be safe unless we’ve gone through the entire library [Inaudible 00:10:17].

Male: Well I know that’s being a concern of mine for pinning too much on WordPress because we have done the odd WordPress install. Almost every time we’ve done there’s been like the next month some sort of vulnerability that we’ve had to just panic over and patch. I haven’t really enjoyed my time in WordPress. I know that’s it gotten better and better as a product but it is a target I suppose for vulnerability.

Male: I guess not WordPress specifically, anything that’s got large distribution like that.

Male: That's the exact same way as any more secure inherently. It’s only that you've got less of a target but as well as that you've got only one stream of code that you've got to order instead of having to order your own code base which you're using for one type of site. This other code base that you're using for another type of site so you've got to keep your eye on sets of potential vulnerabilities.

Male: of course that's the old security [Inaudible 00:11:13] thing that if you don’t have an open source product then only you know exactly how it works and so you know hackers cant pore through the code and go ah ha. This is how I can get in.

Male: Yeah that’s right, because that code base is just not freely available. I guess the pros from my point of view from being the guy that deals with the clients and writes the quotes [Inaudible 00:11:37]. The pros of using a WordPress or a known brand CMS is that there’s the flicker of recognition from the client. Like sometimes they’ll specifically ask for a CMS by name. I have to talk them into using ours. That's not a hard thing to talk them into if it isn’t really a custom bespoke site. Because they understand that there’s nothing off the shelf that’s going to do what you want.

If it is just a simple CMS, then very often the easiest sale for me to make would be to say, we probably use WordPress there or something like that. They just go “Oh yeah cool WordPress I’ve heard of that.” From a sale standpoint it’s actually a negative for me to try and sell Sprout in a simple CMS. I guess the other questions that come up in this particular argument is any CMS that an agency like us with a few programmers in a corner developing is going to be just simply not as good as one of these other ones that we've talked about WordPress, Craft, Expression Engine. Because it’s had so much, so many developers, so many hours put in by many many developers around the world. How do you respond to that argument that ours couldn’t be as good?

Male: How do you measure goodness? Does it fit a particular purpose or is it a general jack of all trades master of none type of thing?

Male: I actually feel like this particular argument is valid if you're a new agency starting out and you're making the decision “Hey let’s build our own right now, do it on our own or go to one of these mature frameworks.” Our framework’s pretty damn mature and it’s backed by a pretty solid [fork 00:13:32].

Male: It’s being used on a big heap of sites in production. Lots and lots of production hours.

Male: We know that the user experience is pretty [Crosstalk 00:13:47]

Male: Lots of user hits, people like it. I suppose it’s got flaws.

Male: I mean if we compare it with some of the new kids on the block in terms of CMS, there’s some lovely user experiences out there that we’ve seen of late. We’d love to implement into ours and that’s what spurred this discussion. I still think it’s a very nice user interface and we still get lots of comments of course. I’d say everybody probably every agency now is probably proud of something like this that they've built. I think that question of well it couldn’t possibly be as good is actually not quite valid. If you've got such a mature system that’s been around for so many years.

Male: We’ve got a known quantity thing there as well.

Male: If you had to build it from scratch for a client in three months or something, it’s not going to be nearly as good.

Male: For people listening on this probably quite a few in the bow of not having an actual CMS yet and looking to do what we’ve done and go down the route of building your own from scratch know what's out there. I mean if you were here making that decision, now with all you know, how do you think you’d be feeling about it?

Male: I think if it was right now and I was starting over from scratch and we were forming an agency, I’d probably end up using something like Craft or Expression Engine. Back when I was contemplating this eight years ago and we were looking for something you that could write heavily custom code in and something that could comply with web standards I don’t regret the decision.

Male: There is nothing really..

Male: I didn’t really feel like there was anything I don’t know eight years.

Male: There was almost no options there was WordPress and a couple of little things.

Male: WordPress supporters would hate to hear this but back then WordPress really did to me feel like a blogging platform. I remember spending I think a couple of days just trying to get the navigation to behave like I wanted it to behave, like with related links and adjacent tree structure. I found it really frustrating on output. I don’t know, I don’t regret it back then, but I guess that's why we are having that conversation now because the world is a different place now. There are some very good frameworks out there, good CMS out there. There's SilverStripe, there’s Craft, Expression Engine and indeed the latest iteration of WordPress is a very good CMS and much better than what it was, I don’t know years ago.

Male: Yes, I will answer your question; I reckon I would commit to one of the existing framework. We are not in that situation. We are in a situation where we have a very mature code base, it’s currently use by a ton of clients to just stop developing and it would be in a way a bitter pill to swallow. We have to contemplate that.

Male: Well in any case, independent of what happens moving forward, there would still have to be maintenance work on the code base for at least a year I would imagine.

Male: Yeah, of course.

Male: Just to maintain the existing client per base. Actually some of the, even if you changed it today, there would be code base to say that would be working five years.

Male: Yeah, you're right because we have clients in fairly big...

Male: We have big bespoke systems and you just are going rewrite those.

Male: Installs and they will continue to work with them. That's fine; it’s not like we’ll forget how to work in Sprout.

Male: No.

Male: You could even change programming language at the same time if you can upscale your developers quick enough if you wanted to, that would be a fairly big undertaking.

Male: That's a big undertaking but it’s possible at the same time.

Male: Yeah. OK. Those are two of the points, it will be worse, not sure that's applicable to us. No one can help you but them. I think that's valid to a degree not in the case of very bespoke systems.

Male: Right.

Male: I suppose the other comment that they make is they're not going to develop very quickly enough for you. Well I disagree with that for the same reason we have a very established code base that we are very very comfortable in. In fact probably one of the reasons why we wouldn’t change is because we wouldn’t [inaudible 00:18:09] other developers quickly and in one of these other frameworks is what we know we can in Sprout. It’s kind of like the reverse.

Male: No [crosstalk 00:18:13]

Male: In case we are very fast and very agile and I think that's one of our strengths our point is totally invalid for a particular instance.

Male: The only other interesting thing here is the comment that he makes which is, and by the way this is our posters article in the [inaudible 00:18:28] because it’s fairly venom but it’s still worth a read. It’s from [Gadgetopia 00:18:34]. He says, “Your content is locked in.” Your data belongs to them when you invariably decide the system sucks and want to move on, how do you get it out? What is their migration plan? Of course the data doesn’t belong to us. Typically these are always hosted...

Male: Some of that is talking about hosting CMSes.

Male: That's right, ours is not a [SAS 00:18:56] product, it’s sitting on space that essentially belongs to the client or is under the client name or we've commissioned for the client. In our terms and conditions, that code belongs to them when we sell the Sprout license that is there's. They can take it to another developer. We don’t put restrictions in place.

Male: We've got data import and export tools at both the SQL level and...

Male: Some can export as the [crosstalk 00:19:21]

Male: Individual table [crosstalk 00:19:22].

Male: I suppose we could if we really wanted to address that argument. We could write knowing WordPress’s API, we could write a total migration tool to WordPress so that we can say, “Well look, if you end up liking our product, we can write you a migration tool to work with.”

Male: We can do it by variation...

Male: You can get part of the CMS.

Male: You can go from WordPress as well as back to WordPress.

Male: That would work for stuff that happens in WordPress like pages and what have you. When you've got custom...

Male: Custom stuff it comes back to that thing

Male: Database tables. Exactly.

Male: Again that's just...

Male: You're never going to be able to support that across the system.

Male: You're never going to do that

Male: If you wrote something in WordPress and brought a whole bunch of custom plugins and stuff, then you want to export that to Expression Engine in the same boat, you might be able to write something that grabs the page and the posts, but you won’t be able to do anything about the custom stuff.

Male: I don’t know what platform you use, each of them wax and wanes in terms of popularity or you know.

Male: That's an important point because you shouldn’t really choose the same ones because it’s popular. You should choose one because it’s good.

Male: Yeah.

Male: When I say popular I mean short term popularity verses longer term popularity. Like WordPress, we keep talking about it because it’s sort of massively...

Male: Its long term popular verses short term hype.

Male: Yeah, definitely. I mean right now the hotness is craft CMS obviously. I don’t know it’s obvious to anybody else but it’s obvious to me. The Craft CMS seems to have been, it’s just going off and they're doing a great job of very discreetly marketing it or without being over the top. They're just providing information sessions and good education and great tutorials and great documentation generally. It’s a really good solid framework. Out of the box, it doesn’t really feel like a CMS to me, it feels like a framework.

Male: A builder tool that you can use to make into a CMS.

Male: It would be some learning curve to just try and create I guess an instance of Craft CMS that feels out of the box like a friendly CMS to a clone. Because off the bat it doesn’t to me. I'm sure you can do that because its power is quite good. Yeah, that seems quite nice.

Male: I mean I guess until you start developing with stuff, I mean we've looked at a few, we've looked at Craft, we've looked at concrete five which I've got [inaudible 00:21:46] respectful, although again out of the box it seemed quite, well almost overly complex from a ...

Male: Yeah, I was going to [crosstalk 00:21:54]

Male: It’s an unusual interface. They’ve gone in a really interesting route with it, but it doesn’t necessarily come off as intuitive.

Male: I’d say you get obviously used to it and familiar with it and once again you will be able to edit it to be more client friendly perhaps. What's the other one? What's it called?

Male: SilverStripe.

Male: SilverStripe, yeah that's a New Zealand company and that's nice as well. That's actually of all of them probably the most similar to Sprout in terms of the way it behaves, the framework behind it, would you say? It’s fairly module like Sprout.

Male: Craft is proprietary isn’t it?

Male: Yes, Craft is not open source although there is a free version of it.

Male: Yeah, and then what about Concrete 5, is that the proprietary?

Male: That's open source for the good project.

Male: Right. SilverStripe is open source as well, isn’t it?

Male: Yeah.

Male: We’d like some paid plugins or something, isn’t it?

Male: I think paid support.

Male: Oh right.

Male: I'm pretty sure.

Male: That's a good point as well because a lot of the client concerns in these articles is if its proprietary and going into the Craft room, customizing it yourself, you're still kind of in a proprietary room, it’s not like someone else can just pick it up and take over necessarily.

Male: That's true, but the difference there is that they've got very publicly extensive documentation. Another developer could...

Male: The problem there is that if the developers of Craft go out of business tomorrow and if we had a bunch of sites in Craft, then we are in latch and our clients are all in latch as well.

Male: Well I don’t know if we would be in a latch, we would have...

Male: Well we wouldn’t be [crosstalk 00:23:34]

Male: We wouldn’t have updates anymore at that point for example.

Male: No, that's right.

Male: We wouldn’t have paid support if we had a paid support contract.

Male: You would have to essentially fork it and...

Male: Create your own version [crosstalk 00:23:43] you have to keep doing your own.

Male: Which probably went out of business they would allow that email licensing.

Male: They would probably have to.

Male: If we've been working on it for a while at that point, I don’t think that would be an issue.

Male: It wouldn’t be a problem.

Male: No, no. I guess that does lead us a little bit to the next option. Let’s say one option is, OK we use Sprout and then just start using one of these more publicly accessible CMSes for a smaller site, that's one option maybe. The other option is just continue using Sprout for everything. The third option is to either make more public documentation of Sprout or open source Sprout completely. Just create either the current version or new a version.

Male: Yeah, so any option is you really know a complete shift to another CMS?

Male: I think I’d almost rule that out just simply because the amount of custom sites we have in Sprout already. I think I’d still see a place for us to have a framework that we use to develop essentially big fat web applications. At this stage I think Sprout makes the most sense to be that application. In your old code bases are going to stay in that system. You might as well keep some skill and up training in your people and your staff and keep using it a bit.

Male: As frameworks go, it’s beautiful to work with. Its lean, it’s intuitive once you've gone around it a little bit.

Male: Yep. I mean I think you can say the same thing for say Craft. Once you get around the concepts. Is that right Josh, you had a bit of a look into it?

Josh: I had a bit of a play. I imagine that yes, a learning curve, what's there at the top of the learning curve? Everything is going to be feeling intuitive.

Male: That's right. Yeah it feels intuitive to us. Of course.

Josh: It’s not a very valid argument in the fact that you would learn anything and get good at anything.

Male: Let’s just consider...

Josh: Then again Craft is also based on [Yii and Fail Yii 00:25:40] log.

Male: Very good stable framework.

Josh: That's good for our work. Like that's been well developed and stuff. That's probably why it was relatively nice to work with it. I’d probably preferred working with that than drupal or something.

Male: Yeah I guess the thing is that we are not afraid to code, we are not afraid to write custom code. If you committed something like craft, like a lot of knocks on craft, is it, “Ah it’s a bit immature, it doesn’t have for example an ecommerce option and stuff like this and its available plugins,” that just doesn’t bother me at all, do you know what I mean? As long as you understand this plugin architecture, you just write your own, it’s no problem. Am I wrong there?

Male: Yes.

Male: That's not really a problem. As long as it’s underpin by like a really solid as you said, it’s underpin by Yii which is a really good custom framework for developing I suppose. The last option though, just getting back to what our options are, is what do we think about cutting this next iteration of Sprout making it open source?

Jamie: I love open source.

Darren: Well look, I think we all love open source.

Male: We use a lot of open source, so it will be good to return some open source back to the code, to light the world.

Male: I personally feel like that's the most exciting option for me.

Male: Yeah, I don’t know whether that's romanticizing it or not and then already regret the amount of support that we have to provide an open source product as substantial as proud and that maybe we should release some other small things, open source first to get a toe in the water, I don’t really know. That is probably the option that I like the most.

Male: What sort of smaller things would we release it that didn’t involving loading [ensworth 00:27:28] full Sprout install anyway?

Male: We’ve got a ton of little interesting pieces of code that a lot of developers out there would be interested. For example, his [dot X paza 00:27:41] that basically you can create a website out of dot x file and stuff like. There's all sorts of stuff that might be fun for other people to develop.

Male: It is. Some new galleries and things like that.

Male: Yes, all sorts of stuff. Yeah, there are lots of stuff that we could and we should I think open source. My main concern is right now Sprout is very much a tool that we can sit down and develop. If you hand it over to another developer, they just wouldn’t know where to start. We need to, whilst we had documentation, we have to rewrite it a way as though someone just never even seen it or heard it before. The documentation will have to really be a lot more, good for both, both of us. It would have to have some kind of installer probably. Our installation routine that we just don’t ... I mean we’ve got our own here but it relies on our tools. It would have to probably have a more prescriptive set of guidelines for developing modules and things like that. I think we can sometimes be a bit free and easy about the way we get modules.

Made: We’ve got to thorough look over the whole co-base and refactoring over the few bits and clean up all the little lose bits and knobs that are everywhere.

Male: Yeah.

Male: What's the negative, what's the knock on going open source with the next version of Sprout?

Male: How does it apply for the current licensing situations? We’ve got...

Male: With our current clouds or with future works as well?

Male: Yeah, it would change things a little bit to get that addressed, so it’d have to be a bit of documentation and chatting to lawyers of course.

Male: Like would you give away the CMS and then license out support offered or give away the CMS and license out modules or give out the CMS and license out the time it takes us to install and set it all up and skin it and all the rest?

Male: If you can’t give out the CMS and license out the modules?

Male: Yeah, I think.

Male: The time to install the skin and stuff.

Male: Yeah. It would be just time and developing custom stuff. I have to think about pre-existing modules and whether we want to include them in an open source package. I think we would want to make available a selection of generic open source modules. Do you think?

Male: There are a few things that are pretty caught to it being a CMS articles, pages, links.

Male: Articles [crosstalk 00:30:10] obviously pages perhaps even basic image gallery.

Male: You would always want some kind of flat market place where people can buy modules. Then we can put a bunch of our own modules on there. These are like classy official Karmabunny market place.

Male: Then only other question then becomes, because a part of Karmabunny road map, we probably will in the next five years not just release open source products, but we may release say a SAS product of some sort, OK? It does strike me that having a track record with a quality open source product might actually be good for Karmabunny down the track. Do you think that that actually would assist strategically that goal? Having an open source product that people will like and top volume?

Male: I imagine so, sort of build in a good community and reputation, a little leverage when you came to try and take that next step, I think that would probably be in our favour.

Male: Yep.

Male: I'm in general agreement.

Male: It’s very discreet, isn’t it?

Male: What about if we rather an open sauce it just solves, as a product in itself in the same way that Craft is doing?

Male: Yeah. It will still be a proprietary product but it’s documented [crosstalk 00:31:37].

Male: It’s documented and itself becomes a product rather than what we do with it.

Male: Yes, yes. That means you end up with a Craft style presentation where maybe there is a free option of it with some limitations and then it just becomes something you license and play for.

Male: Yeah, so other developers could take it and work with it.

Male: I mean either way, whether it’s open source or that way inclined, it’s about the same amount of time and effort for us.

Male: To prepare for use.

Male: To prepare for that. I wouldn’t want to release that an open source product that was half baked in terms of documentation. I certainly couldn’t do that if we were charging for it, it’d have to be thoroughly documented in the affect. Yeah. I don’t know that we've come up with a solution here today, but I think one of the latter concepts is probably to go. I think also I would be open to investigating and spending some time on documenting better anyway.

Male: Yeah.

Male: Also perhaps even creating a migration plan that I can talk a client through if they do want to move to another CMS kind of a migration routine that we can build into Sprouts so that I can say to clients, if they were concerned about being tied into a system, that they can use it to export content to Word Processor or any number...

Male: it could make some kind of tool that does WordPress or whatever CMSes I guess. Just export to that platform.

Male: Yeah just like export WordPress dump file or...

Male: With the exception being custom modules that are too wacky to just simply do any course. I do like pages and use that.

Male: Even those modules have built in and Sprout the ability to export to XML, export to CSP anyway.

Male: Yeah.

Male: I mean I'm sure that a decent developer can take that data and turn it into a module in whatever CMS they want.

Male: Yeah.

Male: OK. Well again we probably haven’t come to any great conclusions, but I think it’s been a really good chat. Probably the next discussion we have to have is if we say that we are looking at one or two options, one being producing an open source version of the next iteration of Sprout or licensing in some way for [crosstalk 00:33:57] use or something, but part for money, then I guess we have to sit again and have a conversation about what's the pros and cons of doing both of those. Maybe that would be the next behind closed doors counting how many podcasts that we have. All right. Well that's it. Thanks guys.

Male: Cheers.

Male: Cheers.

Male: No problem.

Speaker: Upgrading to the new beginning.

Tagged with:


Tell me more...

More web rambles on similar topics

Want to get webby with us?

We’d love to hear from you