Aaron’s Potlatch

In creating software, we often are faced with build vs buy vs combination (integrate). While creating a software application, I find that we have a series of patterns that repeat itself related to needing features that are “non core”. Some examples:

• One of our teams an application needs a “Tiny url type functionality” only internal, secure, private to have less brittle url’s. We have ~30 different web based applications that make up our environment, and invariably we break others when we update one and the “link api” changes. We want a means of indirection, so if the end “link api” changes, we can change it on the central “link server” instead of updating the other 29 software applications. See info on PURL’s and a recent project to update the actual PURL sever.
• We also need content (news) to show beside our custom software on the right side context. We need to notify the users of changes to the software, impending outages/upgrades, etc. Since these don’t happen that much we update them statically since we are so focused on “Core” functionality.
• We send out email, and find ourselves creating email templates stored in our own db, or email template management admin tools also.
• We also find ourselves creating a Help system to author little tips/help built into our application. None of these do i consider “Core” to why our application exists. The business

Diagram showing the Core vs. Non core aspects of our applications.

In Addition, we have received numerous requests for other features that have just been to low on the priority queue to ever find time to add to our systems also shown in above under non core aspects of applications.

So, Demisauce’s charter is to provide very, very easy to use through library integration with a server that has admin tools to edit content, but that content and services are utilized by applications via web services.