What We Have Here Is a Failure to Communicate: The Value of Making Grants Management Systems Talk to Each Other
There’s an old computer joke that goes, “How does Bill Gates screw in a light bulb?”
Answer: “He doesn't. He declares darkness the industry standard.”
That may sound a bit harsh in describing the state of affairs in grants management software, particularly with the recent introduction of new products. But for too long foundations have grown accustomed to eating our vegetables like good children and accepting what the vendors offer rather than getting what we really want.
This seemingly reactionary viewpoint isn’t to say that the makers of grants management software are evil. In fact, they really do try, and in many cases, succeed in making great products. It’s just that once they give us something that’s really useful, they restrict how we can use it.
Suppose, for example, you bought a state-of-the-art television set, say a 60-inch LCD flat panel, 3-D beauty, only to discover that the only channel you could get was HBO. Now, there are some great shows on HBO, but you couldn’t watch the Red Sox, or NCIS, or that Seinfeld rerun for the 17th time.
Wouldn’t it make sense if we could buy a grants management system that met most of our needs, and then combine it with other programs (or hire a programmer) to make it do everything we want it to do?
In technology terms, making this happen requires an application programming interface, or API. An API is a program that allows one program to access the underlying code of another. That way, data can be exchanged between them. In other words, they can talk to each other. Why is this useful? Suppose you really like how a particular program processes data, handles workflow, or the power with which you can do searches in the database. But you also have the need for a custom-designed interface that enables other users to view the data, such as an online application system. The database you have may allow you to create online applications, but not necessarily in the way you really want. With good API’s, you can design your own interface, or combine one system with another, getting the best of both worlds.
Sounds simple, so why aren’t all of today’s systems designed with good API’s built into the program? There are a few reasons for this:
Proprietary systems are predictable. When programmers tackle a problem with a known set of limits, they can reduce the number of issues they, and you, will run into. Ever wonder why Macs crash less frequently? It’s because they are not designed to work with every program or piece of hardware under the sun.
Technical support is difficult. When something goes wrong, who ya gonna call? The other guy! No one wants to be responsible for supporting a product with an unlimited set of unknown add-ons.
It’s bad for business. This is probably the most likely and obvious reason why companies resist opening up their systems. The premise is that if the customer can go elsewhere for certain functionality, they won’t be buying your solution.
The “bad for business” argument may sound convincing, but it may also be short-sighted. After a long, barren stretch of offerings, the last few years have seen a proliferation of new products in the marketplace. Spurred primarily by the popularity of web-based, hosted systems, we have been introduced to such programs as Cybergrants, Foundant, GrantedGE, Salesforce, and Philantech, among others. Though the number of users is still quite small, these companies are beginning to make inroads in stealing away market share from industry leader Microedge. Yet most of these products aim to be all things to all people, meaning that if a customer wants to use the capabilities of one system, they need to abandon the other. Allowing an existing customer to combine their product’s functionality with that of another program could mean the difference between retaining their business and losing it.
One new product on the market threatens to turn the status quo on its head: Fluxx. No, it has nothing to do with the flux capacitor in the trunk of Michael J. Fox’s DeLorean that took him back to the future. It is the final output of a project, originally called Solpath. Solpath, which began its work in 2005, was made up of a group of techie philanthropists who decided that it was time for the users of grants management systems to decide for themselves how their software should work. After spending two years designing specifications, they searched fruitlessly for the funding to build the system until the Energy Foundation came through at the last minute to foot the bill. The result is an open source system, meaning that the underlying source code is completely unlocked, changeable to anyone who has the ability to do programming, and is available at no cost.
Wow, you’re telling me I can get a shiny new grants management system for free? Well, yes and no. Yes, if you happen to be a computer programmer, but no for most of us who will need to hire someone to shape Fluxx to meet our individual needs. Another thing to consider is that the product is so new that there is limited functionality at this time. For example, there are no built-in connections to third party software, such as Microsoft Office; there is no online application and reporting system, and for now there is no giant user-base to consult (or commiserate with) when there are questions.
On the other hand, what you do get is a beautiful, “iPad-ish” look and feel that excels at contact management; an intuitive interface; sensible and powerful search capabilities, and best of all, the ability to build exactly the system you want. The intent is that over time, users will create better add-ons and improvements that will be made available, for free, to the entire Fluxx user community, in the same way that the operating system Linux and web-authoring programs like Joomla and Drupal were designed. It is a utopian dream (for the geeks among us who dream about such things), but it is within reach.
Open source may be a panacea for tech-savvy foundations or for those with unique needs, but it shouldn’t be the only way to get the system you want. A little flexibility from the established vendors out there would go a long way toward improving the way foundations manage their grants. But a warning for those who choose to keep their heads in the sand: foundations may be slow to change, but they won’t overlook a better mousetrap forever. As famed programmer and American software freedom activist Richard M. Stallman notes, “If programmers deserve to be rewarded for creating innovative programs, by the same token they deserve to be punished if they restrict the use of these programs.”
Jonathan Goldberg is the Director of Systems and Communications at the Surdna Foundation. In that role he oversees grants administration, information technology, and communications. He is also a die-hard Red Sox fan.
GMN Examiner
Editorial
Entertainment
The GMN Examiner Editorial Team
The GMN Examiner is published three times a year through the dedicated efforts of GMN members and volunteers.
Editorial Team
Ericka Novotny – Co-Editor
Allison Gister – Co-Editor
Deborah Bloom
Melissa Boilon
Peg Butler
Bobby Fergerstrom
Kim Foster
Bonnie Rivers

