I have some exciting news. For the last few months, I have been working on a new collaboration called OpenIssue, which is a growing, diverse, self-reflective and constantly-learning team. We are focused on delivering quality web technology solutions to nonprofit organizations and social enterprises.
As you know, I have built a long-time expertise in open source software and web applications, particularly Content Management Systems (CMS) and online database systems, including CRM. Thomas Groden, my new business partner, has expertise in Software-as-a-Service Constituent Relationship Management Systems (CRM), as well as much more broad expertise in technology infrastructure.
All technology implementors have to choose their tools (unless they run a very large shop) and we have decided to focus on implementation of both Salesforce.com and CiviCRM as CRMs, and Drupal as a CMS. We are keenly interested in building on our expertise to integrate these open platforms in really rich ways, to allow organizations to create great online applications.
I’m excited to be a part of a team – I’ve been a soloist for a while, and it’s nice to build collaborations, and work together with people with shared ideals on larger projects than I’d be able to take on alone. And I’m really excited by the set of technologies we’re working on, and the kinds of applications we’ll be building with these technologies.
And you can follow us on twitter.
Tagged as:
civcrm,
CMS,
Consulting,
convio commonground,
CRM,
drupal,
nptech,
salesforce
The dust is settling. I looked over Allan Benamer’s post on the Convio and Kintera initiatives, I looked harder at the Convio Open and Kintera Connect docs, and I also had a chat with some Kintera folk. I have a few comments.
Allan is right – the Kintera API is more comprehensive, and provides for more flexibility than the Convio API. Of course, the API was only one part of Convio’s initiative, so I do still think they come out ahead, a bit. But it may well be that for more complex integrations, the Kintera API will provide more power.
REST vs SOAP: Kintera seems to have chosen the “more power, harder to code” choice. I could argue it either way.
Methinks vendors in this space still just don’t grok, really, what “open” means. While I appreciate that one can, theoretically (I have yet to test it) easily become a “partner” with either company – but that doesn’t quite count as open. Allan hit the nail on the head when he said:
Again, this is a lesson in Web 2.0 transparency both for the sector and the vendors who serve it. Control? Let it go. I really mean that. From both a business point of view and from the point of view of how our sector should work to heighten transparency in society at large, there’s no reason to limit the ability of coders to learn about and discuss the API at hand. And the big guys have already done this work, check out the way Google and Amazon distribute their APIs. Those shine as industry-standard examples of how open APIs need to be distributed.
He’s right. Open it up, let anyone bang on test data to try things out, and you never know what might happen. The drive toward open everything is pretty inexorable, and the pressure is only going to get greater.
I listened in on the call with Kintera folks about their new platform, called Connect. I was mostly curious about how open this platform will be, and what the future holds for them. I have become fascinated by the ways the CRM/Fundraising space is changing so rapidly.
Basically, Kintera is taking directly from Salesforce’s playbook. There are two initiatives that they have that I’ll talk most about, their “Connect” initiative, and their data warehousing initiative. These are, for pretty obvious reasons, the most interesting to me personally. They will also be doing some serious UI overhauls, and upgrading their CMS. They also are opening a new data center, as well as bringing Akamai technology into the mix.
The Connect platform is a set of APIs, starting with the contact and payment sets of entities, that will allow access (via SOAP 1.1) to the data in the Kintera platform. Basically, third parties will be able to build applications which will allow two-way communication into the platform. The APIs will be without cost.
The data warehouse initiative is to allow their customers access to large amounts of data for reporting and data mining. It seems like it will start out with a local query system, then will be opened up to allow third party development of data analysis tools. That part looks very interesting.
A couple of annoyances: the documentation for the APIs aren’t up yet, and the sample code they are going to publish is in C# and Java! Now I’m sure that there are a lot of large Kintera customers that might be implementing other applications that will be written in C# and Java, but it seems to me that this is, in fact a pretty big red flag that they really don’t have a feeling for the technology that the sector is using. Code published in PHP and Python would probably get a lot more people up to speed and interested in building stuff that will integrate with the things that a lot of nonprofits really use. I mean really, how many nonprofits have stuff written in Java? Small minority, I’d bet. (I guess the C# would be useful for the Windows crowd.)
On the whole, though, I applaud them for seeing the light, and opening up their platform. It will be interesting to see where this leads them.
I’m throwing up my hands. Y’all will just have to live with overlapping series. I have too many ideas be sequential. I promise (!) more on Open Standards and Benkler (actually, Benkler is up next – I’ve got two chapters to review).
I’ve been using databases since I was a grad student in the 80s, and I’ve been designing and developing database-driven applications for the web since 1995. I’ve been using varied Unix-based databases since then (as well as others including Access and Filemaker Pro), and most have been open source.
Although I’ve been using databases for a while, I’ve decided that I’m going to focus specifically on open source databases for the next while, and, in particular, the different kinds of open source solutions that are possible for desktop database systems, or systems that might be server-based, but need a desktop front end. I’m particularly interested in the open source technologies that are coming down the pike that might bump Access from it’s perch as general-purpose nonprofit desktop database king, and that can provide nonprofits with flexible, robust data management solutions.
So here is my current survey of the landscape. I’ll be working a lot with Open Office, and hope to design some screencasts using Open Office Base sometime in the next few months. I’m starting this series off with just a list of the server-based DBMS. I’ll be talking next about desktop DB options (which mostly use these as backends,) and then last about ways to put this all together in an all open-source landscape.
Server-based DBMS (DataBase Management Systems)
- MySQL – MySQL is, I think, the most popular, and best known open source DBMS. It is cross-platform. It is the most popular because historically, it has been the fastest of the open source DBMS, but it has always lagged behind in terms of ACID compliance and other features. You can access a MySQL database via many many different drivers that people have written for just about any programming language. It is also possible to access MySQL databases via ODBC (Open DataBase Connectivity) or JDBC (Java DataBase Connectivity)
- PostgreSQL – PostgreSQL has always been my favorite. I’ve been using it since it was called Postgres95 – before version 6. (Wikipedia has a great entry on PostgreSQL, including some history). PostgreSQL has always been ahead of MySQL in terms of ACID compliance and robustness, and still is. It lagged behind MySQL for years because of speed issues (it was much slower,) but that has changed with the newest versions, such that in fact PostgreSQL is faster and more scalable than MySQL. PostgreSQL is also cross-platform, with binaries available for Linux and Win32 from Postgresql.org, and Mac OS via Darwin Ports. A PostgreSQL database can, like MySQL, be accessed via APIs written for just about all programming languages, JDBC, and ODBC (which I have quite a bit of experience with.)
- Firebird – this is a newer kid on the block, sort of. It has a very long history, though, since it is based on Borland’s InterBase codebase. It’s doesn’t have nearly the user base, or the amount of available tools as the others, but InterBase is a pretty interesting product, with some good features (like a small footprint, server performance tuning, and a great rollback and recovery system.) It is also cross platform.
- Apache Derby – a DBMS written entirely in Java. This project has a small footprint, and is designed to be easily embedded in other Java projects. It comes with a scripting language and interpreter, called ‘ij’ which is how you can interact with Derby on the command line. Also, of course, you can use JDBC is a way to access Derby. I’ll be doing a fair bit of experimentation with Derby (’cause I’m curious.)
- SQLite – a small footprint C library that implements an ACID compliant DB engine. It has a command-line tool, and it is possible to use C/C++ and Tcl for database access. Unlike the others, that are released under varied open source licenses, the code for SQLite is public domain.
- There are a few others (see list here,) but they are either research-focused (like Ingres,) developed very little, or have small user bases, and seem not relevant to nonprofit technology.
Nonprofit technology take home lesson: MySQL is certainly the leader – it’s most commonly thought of as the “M” in LAMP (Linux, Apache, MySQL, PHP/Perl/Python), which is a nptech web mainstay. I’d argue that PostgreSQL is a better choice, but for most nptech applications, it doesn’t matter – what matters is what your tech/consultant knows, and that’s much more likely to be MySQL. The others are most likely of interest to pretty small niche groups, for specific kinds of projects.
Technorati Tags: databases, opensource
I’ve been beginning to think a lot about databases, and where they are going. I’ve been using databases now since grad school, and relational databases for the past 10 years or so. There have been two specific advances in Web 2.0 that might, in the end, change how we think about databases.
This is described well in a post on O’Reilly Radar, which describes what Google did when it was creating a new bug tracking system. They, of course, have the worlds most kick-ass full-text searching system (I’m not sure whether that’s Web 1.5 or 2.0.) So they combined that system, with specific kinds of tagging and metadata, to decrease the structure of the database of the bug tracking system – they were encouraging people to just put in lots of text in a free-form field.
It made me think – how many kinds of databases that we create and use could be simplified by adding tagging, and really good full-text searching? I already can imagine something like an event management system, or some kinds of content-rich applications that depended upon highly structured relational schema, that could use this kind of new idea. Come up with one good full-text and metadata search functionality (or use someone else’s) and trim down the time and energy both creating the schema, and entering in the data, at the same time as you enrich the content.
I kinda like it.