Better, Cheaper Faster Semi-Custom Apps
Some websites don't need programming at all. Just set up a Yahoo! stores or a wordpress account and you're done. And if you've got (say) $50k+ for some heavy duty custom programming and access to a great team of coders, you can build an application that has an exceptional UI and/or other capabilities that will really differentiate your business. But many web apps fall in the middle - what I'd call semi-custom apps.
They may include commerce, content management, document management, maybe some community building features. There are custom business objects with custom validations and workflows, but there probably isn't anything that unique about the app. It's another cms with custom objects and display templates and integration with your back end document management system or a custom store with simple inventory integration with your mainframe and some funky custom business rules for calculating customer discounts based on their band, the category of product and their total purchases over the last rolling 24 month period. I call these semi-custom business apps and I think they're going to get a lot better, cheaper and faster over the next couple of years . . .
At SystemsForge, we specialize in these semi-custom apps. We've spent a lot of time refining our sales, specification and quotation processes. We've created tooling to speed up and/or automate the description and development of the apps and have worked carefully on our business model to allow us to develop extremely high quality, very affordable apps while still being profitable. And I'm pretty sure we're not the only ones. We've got to the point where now many website development companies just hire us to do the programming and get better apps faster, cheaper and more consistently than by doing the coding in-house. They add graphic design and project management and make most of the profits from the projects.
For shops that focus on larger truly custom apps, this won't have an impact, but if you build apps where much of the functionality could be generated, what do you think will happen to the price of developing such applications and what will be your strategy for handling that over the next 3-5 years?
Thoughts appreciated!
I imagine there are some similarities to the way SystemForge works, although I know you guys use external DSLs (probably in XML) to allow the applications themselves to be synthesized across a variety of server platforms (CF, PHP, C#). That's a key difference though and I imagine it would make it much more difficult to do something like the web-service based plugin manager where you can get sub-applications from 3rd parties. So I imagine although you've probably done a forum for a given client hundreds of times over, the entire forum for all those clients was still developed in-house top-to-bottom. So I'm sure it ultimately doesn't require a huge investment of time to synthesize a new forum for a new client now that the basis for it is well established.
On my end however, I'm pushing to create an environment in which that "establishing the basis" part largely goes away because it's been established not by a team of 5 or 10 or 20, but by a team of *hundreds* of developers, most of whom aren't in-house. What you're left with is working on your core business (if you have one other than building these custom apps), and whatever customizations you make for individual clients. Literally anything that's not part of your core business or client customizations should go away.
We're not there yet. The onTap framework has been on RIAForge since mid-december of 2007 and it hit 800 downloads just the other day, which means almost 2.5 downloads per day. As more people become involved in it, I really expect it to snowball and there to be lots of pre-packaged plugin applications becoming available. They may not all be free, but I expect to see a lot of them packaged as a free core app with some additional features for a reasonable price. :)
Definitely similarities. We also have reuse of features, but instead of reuse at the code level we have a package manager that allows you to select the packages you want which in turn selects the statements in the dsls and generates the dsl data required to implement the packages. I like this approach as it allows for easier customization of standard components rather than trying to edit the code for a forum from a third party because you want to change the way it handles authentication or moderation or whatever.
That said for your use case it makes perfect sense to go the other way.
Yep, it's probably easier to customize something you wrote yourself. I've spent a lot of time however laying a groundwork in the onTap framework to make it easier to customize 3rd-party apps -- specifically, to allow you to do that *without* editing their code, which you can't do (as far as I know) with any other framework currently. I think this is a critical ingredient in the environment I'm trying to create, *because* editing someone else's code makes it much harder to upgrade to a newer version of their application.
In today's market making customizations to a 3rd party application cause big big problems when you want to upgrade that application later. That's much less true of plugin applications for the onTap framework. So say you installed the onTopic forum -- if you made your customizations in the prescribed way, then you won't have edited any of my code and you can probably upgrade to the new version in a few minutes by going back to the plugin manager and clicking "install" for the new version. If on the other hand you decided to just edit my templates, then you're going to have a problem (which just takes you back in time to the way 3rd party applications work today). So in my plugins there tend to be a lot of cfparam tags in the controller logic. :)
But I'm of the general opinion that this software ecosystem I'm trying to create wouldn't work at all unless those specific issues were well addressed, which is why I placed such a focus on them. I think having the web-service for plugins and streamlining that whole process including the upgrades is going to be a key factor in getting buy-in.
Reuse at the design level and app synthesis makes more sense of course if you are switching between different platforms like CF, PHP, etc. the way you guys do at SystemsForge. I just don't have any interest in working with PHP or C# which makes my strategic choices easier. :)
Daemon build what we call "tailor made" applications from existing code libraries on a daily basis. That said, we tend to be building larger, more bespoke applications, and to tighten things up cost-wise we'd need to start offering much more defined and unyielding feature sets. Much of your success in that market would boil down to the sales process I suspect.
[1]: http://www.farcrycore.org/