Posts tagged as:

opensource

How to deal with technology change

by Pearlbear on February 18, 2011

I saw a call for a ColdFusion developer on an email list I’m on, and I couldn’t help but think about technology choice and change, particularly in the website world, and how nonprofits deal with technology change (or, don’t deal with it.) ColdFusion has been around for 15 years (more than a century in Internet time), and although it has improved and developed, technologically, it has been surpassed by its successors (including PHP, Java, Python, RubyonRails, and even .NET.) But this article isn’t about CF, it’s about technology change.

Technology is a rapidly moving beast. And the pressure to move forward, fast, is right there, always. It’s part of our culture, from the advertisements to the neatest, newest, coolest phones, to the new TV you should have. And then there are those of us in the Nonprofit technology community who are constantly on the bleeding edge of the next thing, whether it be hardware, software, or web services, are constantly talking about it, and how it’s going to make it easier/better/faster to change the world. Although I often get snarky about this, I am aware that I am guilty of this, too.

Most nonprofits are not run by geeks. Most nonprofit leaders think of technology as something in between a useful tool to be leveraged, and a necessary evil. They are resistant to rapid changes in their technology, as well they should be. And, they depend on geeks to help them get things done.

I have a story about nonprofits with a website they can’t leverage for their mission. Although complete fiction, this story will feel quite familiar. And I know I’ve been a guilty party in a real story at some point in my career.

A small nonprofit has a small staff who know a lot about their mission, but nothing about how to create a website. A friend of one of the board members is a web developer. They hire that web developer to put a new site together. The developer waxes poetic about the capabilities of this platform, called AmazingWebCreator. They imagine the developer knows what they are talking about. The developer builds the website, then goes away. The organization is happy for a while, they have a website with pages they can easily edit using a web form, which is more than they had before. Then in months, or years, they want to add some new pages, or a new section to their site, and a widget on the side. But they realize they don’t know how to do that. They call the developer, who is busy now using AmazingWebCreator on some huge project, or has moved on to SuperDuperWebCreator, and doesn’t have time for them. They have to bring in another developer, who knows AmazingWebCreator, which may cost them time and $.

Of course, the critical factor here is what is “AmazingWebCreator”? If it is a relatively new CMS (like WordPress, Drupal, Joomla and others) they may not need to bring in a new developer – they may just be able to get a book, or buy a video to teach them how to use the web interface to create new regions and widgets. If “AmazingWebCreator” is a platform like RubyonRails, Django,  .NET, Java, or ColdFusion, they are most likely going to have to hire someone to do that work for them, and depending on the platform, those developers may be either few and far between (ColdFusion) or in high demand, and therefore relatively expensive (RubyonRails, Java.) Worst, of course, is if AmazingWebCreator is a proprietary, custom CMS that the developer wrote themselves in 2002, and no longer supports.

How is an organization supposed to know how to make an informed choice about a website platform? I have a few suggestions:

1) Assumptions: First, assume the person/people who develop your site might not be around in a year or so. And assume there are things you can’t conceive of now that you’ll want to do in a year. Don’t assume the platform that your buddy chose for their organization’s site is the right one for you. Don’t assume that the most popular platform is necessarily the right one, either.

2) Feature set: Garden variety website, or  very specialized functionality? (By “garden variety” I don’t mean brochureware. I mean average, normal features of most nonprofit organizations. These include such things as donation buttons/pages, membership lists, blogs, etc.)

3) Platform choice: Look at a number of things – if it’s open source – how many developers are there? How many people use it? How easy is it to find developers? Will most new functionality be able to be added via web interface, or will it require back-end coding? Is it a custom CMS, written, maintained and supported by a single shop? (NEVER, EVER, EVER CHOOSE THESE. Here’s why. Luckily, they are an endangered species.) If it is proprietary, or software-as-a-service, are the extra features really worth the cost? Are there many consultants and developers who can assist you with this platform?

4) Lifecycle: Is it early in the life of the platform, at it’s peak, or late (or very, very late)? Bleeding edge might hurt, aged platform might crumble underneath the weight.

There are lots of folks (I do this on occasion on this blog, and Idealware is a great resource) that can provide you with information about specific platforms, and comparisons between them. Read, read, read, and ask many questions before you decide.

Tagged as: , ,

{ 2 comments }

eBooks #2: So you want to e-publish? Mechanics…

by Pearlbear on February 16, 2011

As most of you know, I’m a writer. I write a fair bit of science fiction, and also write other stuff. Lately, I’ve been thinking a lot about what I want to do to get my novels out in the world, and have been greatly influenced by Cory Doctorow in terms of copyright (or, more accurately, copyleft). Obviously for me, publishing eBooks is going to be something I do at some point, perhaps sooner rather than later.

I’m talking in this post about self-publishing eBooks. What are the options, and how do you go about doing it? Since this is a technology blog, and not a marketing blog, I won’t talk about the details of getting an ISBN number, or getting nice looking cover art, or getting the word out, etc. There are also avenues that will allow you to sell both your print book alongside your eBook. All of those issues I’ll leave to other folks. I’m going to talk here about mechanics of just eBook publishing.

Mechanics

If you want to put your book into formats that the widest variety of people will be able to read, think about these two important factors:

  • Distribution avenues: Amazon, Barnes and Noble, Google and Apple, would be the ones I’d focus on, as well as whatever other avenues you want to use to get your electronic files out there.
  • Devices: Kindle, iPad/iPhone, Android Tablets/Android Phones, Nook, Computer (in that vague order of preference)

This will define what steps you need to take to get your manuscript into eBook format.

Amazon has what’s called “Kindle Direct Publishing” – how you can self-publish your book on Amazon. There is a lot of information there on how to get going, including how to get your document into the right format. You can either upload a .doc or .docx file, or a mobipocket format file.

Unlike Amazon, which puts all self-published and publisher-published books into the same pot, Barnes and Noble has this thing called “PubIt!” It’s a bit segregated from the rest of the books in the Nook store. You need to jump through several hoops to get registered, etc. Once you do, your book can be uploaded either as a .doc or .docx, or you can make an ePub version to upload (more on that below.)

Apple also has a system by which you sign up to sell your books in their iBookstore. They also use ePub, so you’ll need to get your book into that format.

Google also makes you join a partner program to publish your book. “Google Editions” is the process by which you get Google to sell your book. In that case, you need to upload an ePub version. Nicely, Google allows you to distribute your eBook without DRM, an option no other vendors seem to have.

(This is sort of an off-topic digression, but it’s interesting, so I’ll insert it anyway. From what I can tell, Barnes and Noble is the only one of the list of these outlets that really distinguishes between self-publishers and regular publishers in the experience of customers viewing/searching for eBooks. In fact, Google and Apple seem to have the same exact back-end process to get books sold, whether you are a big regular publisher, or little ol’ me sitting in my living room…)

Formats

OK, so now that we’ve gotten the bureaucratic crap out of the way, how in the bleep do you get your book into the proper format(s)? I wrote a blog entry a bit ago on eBook formats. The distributors above (plus perhaps your own distribution process) necessitates moving your manuscript from the word processing format you wrote it in, to some other format. I’d say you eventually want it in three different formats:

  1. PDF
  2. ePub
  3. MobiPocket

PDF is easy. MS Word, OpenOffice.org, and LibreOffice (a recent fork of OpenOffice.org – that’s another blog post) have PDF export facilities, so that job is easy. Make sure, of course, that your manuscript has the right types of cover pages, etc. that are standard for eBooks. (Here’s a nice, short guide.)

There are many methods for converting files to ePub and Mobi format. It depends on your platform, your budget, and your technology skillset:

  • epub-tools: an open source, command line set of tools for conversion to epub format. (free)
  • Calibre: a cross-platform suite of tools for ebook management, conversion, etc. I haven’t spent much time with it yet, but it’s free, and seems like it has a pretty nice feature set, including conversion to epub and Mobi. (free)
  • Adobe InDesign: the rather expensive desktop publishing program includes, apparently, conversion to epub (but not to mobi.) ($$)
  • ecub: a cross-platform program to convert files to epub and mobi. (free)
  • Jutoh: another cross-platform program that does multiple format conversions. ($)
  • odftoepub: an OpenOffice.org plug-in for conversion to epub format  ($)

After you create your files, you’ll want to look at them, to see if they worked well. Obviously, checking them out on as many devices as you can would be good. You can sideload any of these files to different devices to test them out. You can also use the following tools to independently view your creations:

One small note: Unlike ePub, which is an open standard, Mobipocket was a company that had it’s own format, and was acquired by Amazon in 2005.

Tagged as: ,

{ 5 comments }

Salesforce.com and Ruby on Rails

by Pearlbear on December 17, 2010

Programming languages and I have issues. By now, I’ve learned quite a number of them (I think 9 by last count), but for some reason, I seem to choose my work on them just at the top of the curve, or as they are going down. I have yet to manage to pick one early. I learned C at the height of its popularity, just as C++ was beginning to rise. I learned Fortran when it was almost dead, mostly for fun. I learned Pascal toward the tail end of its reign. In the late 90s, I chose to write a CMS in Perl instead of PHP. Dumb idea.

I’ve been moderately interested in Ruby and Rails for years now, although I haven’t yet spent very much time getting my hands really into coding Ruby. As pretty much all of you in the Salesforce.com world know, Salesforce.com agreed to buy Heroku for a pretty big chunk of change. I’d played with Heroku a little a while back, and I thought it rocked.

What is Heroku? Heroku is cloud Ruby on Rails. Build a Rails app, and deploy it on Heroku. It’s pretty sweet. So why would Salseforce.com buy it?

On one level, it makes über sense to me. As someone who has managed to learn some Apex, which is, frankly, somewhat of a monster of a programming language, it’s pretty clear that it’s not super easy to build complex apps using it. It’s like Java in heavy chains. A well-joined RoR & Salesforce.com platform, all in the cloud, would simply rock. (In case you are wondering, there already is a Ruby toolkit for the Salesforce API, although it looks like it only works on Rails 2.3, not 3.)

One another level, it’s fascinating. The culture of the Ruby and Rails world, the open source, community-driven, gift economy meritocracy, is very different than the Salesforce.com world – proprietary, business oriented, certifications-focused world. Of course, these are stereotypes – there are plenty of business-oriented Rails folks, and plenty of open-source oriented Salesforce folks, but the worlds really are culturally very different.

I’ll have a post soon where I talk in detail about why I think open source has both won and lost the open source vs. proprietary war, but this particular intercultural marriage will be interesting to watch. And the great thing is that our company has had such a marriage for a couple of years now, and it works.

Anyway, I’m dusting off my Ruby books, and diving in. Fun times!

Tagged as: , , ,

Betting the Farm

by Pearlbear on April 16, 2010

Countless nonprofits flocked to Ning to create social networks. Since I’m not a social media guru, I’ve generally kept my opinions about this to myself. But now that Ning isn’t free anymore, I’m going to carp some.

I think over the course of lo this last few years, I have blogged or tweeted about this very phenomenon what feels like countless times. Nonprofits find services for free. They start depending on them. The free services disappear, for business reasons. The nonprofit community gets up in arms. Lather, rinse, repeat.

There is nothing wrong with software or services that don’t cost anything. Nothing at all. But if you are going to bet the farm, make sure you know what the risks are. Using free services is fine, but know why they are free. Are they free because the company behind them is an ad revenue machine and uber profitable (Google)? Is it free because it’s open source (Drupal, Elgg, Word Press)?  Is it free because it is a profitable company that has a clear and well defined donation program (Salesforce.com)? Or is it free because it is a start up in search for a business model (Ning)?

There is an effort afloat (and a petition) to get Ning to make nonprofit and educational accounts free. I’m not holding my breath. They eliminated 40% of their staff. They are feeling pinched, and need to stop their burn rate. I don’t know how charitable this will make them feel. And even if they do, there is no guarantee that Ning will even survive.

Anyway, if you’re looking for a great social network management system that won’t get pulled out from under you, try Elgg. It’s open source, and out of the box, it does just about everything Ning does, without the need for the deep setup required to set up Drupal like Ning. It has an active developer community, and is growing.

Or, if you look for another free service, make sure you understand the risks, and be prepared for possible disaster if it’s a startup in search of a business model.

Tagged as: , ,

{ 18 comments }

Why use contributed Salesforce modules for Drupal?

by Pearlbear on March 24, 2010

Lobo’s comment on my post yesterday prompted me to complete this blog entry that I’ve been ruminating on for a while. I wrote a blog entry a while back on the state of Drupal/Salesforce integration. What I didn’t say is that a number of shops that have done Drupal/SF integration for production sites chose not to use the contributed modules – they built (or are building) their own custom Salesforce/Drupal integration modules.

A few months ago, in preparation for a couple of projects, and a big push into this area for our company, I was faced with a strategic choice – go it alone, and build our own integration module for client projects,  or plunge into using and working with the contributed salesforce modules. Truth is, it wasn’t really a choice for me – I’ve got using and contributing back to open source projects in my DNA somehow. Although we certainly could have chosen, like others, to go our own way, we have committed ourselves to using, and contributing to the modules on drupal.org.

What we lose:

  • Complete control over development process and direction
  • Not having to fix other people’s bugs in order for stuff to work

What we gain:

  • Not having to reinvent a number of wheels
  • An easier upgrade path
  • Build on the work of others
  • Collaborate and learn

The work done so far on the modules is really solid – and it’s getting better. There is a great new maintainer, and increasing activity and contributions. There are also a number of other module integrations (like Ubercart, Webform, and FeedAPI) that are moving forward. Integrations with Views and Actions are also moving being considered (it’s instructive to look at the issues queue). This is stuff that would be hard to match, and makes building integrations for different kinds of sites easier.

So beyond just my own personal preference, I think that there is much benefit, both for our clients, and for us as a company, in hitching our wagon to theses contributed modules instead of going it alone.

Tagged as: , , ,

The easier it looks, the more expensive it will be (or, how to avoid clusterfrack projects)

by Pearlbear on March 23, 2010

As most of you know, I’m a very long time veteran of web application building. I’ve been involved in web application development basically since they started – when a cgi-bin folder with some perl scripts to process simple forms was the norm. Until just a few years ago, there was very little sophistication about the user experience in web applications – what mattered most was functionality. and to make sure there weren’t too many errors when users did unexpected things.

I’ve considered myself pretty successful at both helping clients navigate the tough waters of web development projects, as well as accomplishing web projects for them. Recently, though, I had two projects that ended up, for wont of a better term, clusterfracks. And I’ve spent a lot of time lately trying to figure out what lessons I need to learn from those projects – what can I take away from them so I don’t make the same mistakes again. They were both custom web applications, both projects that I was a strategic, rather than engineering, partner on. Both projects were attempting to accomplish pretty sophisticated database functionality (such as case management). Functionality I knew how to get done, because I’d accomplished it before – so I had a very good feeling for what kind of code it would take to accomplish the task (and, ergo cost and time.) But what I hadn’t taken into consideration is how slick, AJAXy, easy to navigate, and easy to understand user interfaces people have gotten used to in the last few years. And, frankly, have come to expect. And how unwilling people are to sacrifice that for raw functionality.

I did a lot of self-examination: where did I go wrong? What could I have done differently? Was it the client? The developers? Me? I realized a fairly simple truth. It was all three.  In reality, I should have looked at the budgets of those projects, and looked at the clients straight in the eye and said, “double, or triple the budget at least, or don’t do the project.” And walked away if they insisted. The vendors should have bid triple what they did, and had more user interface expertise on board. The clients should not have expected to get slick 2009 functionality for a mid 5-figure budget.

The easier a user interface is to use, the more money and time it took to create. It’s that simple. What most nonprofit decision makers don’t completely realize is that the interfaces they work in every day when they shop,  or tweet and facebook, or use other online tools, are the product of millions and millions of dollars of venture capital, or, in some cases, hundreds of thousands of person hours of work in open source projects (or some combination of both.) Ground-up custom applications, even when written in great frameworks like Ruby on Rails or CakePHP, which save all sorts of development time, just are not going to have the user experience people are getting more and more used to without very serious investment of time and expertise. In addition, most small development shops don’t have the user interface expertise on hand to accomplish that task, even with a hefty budget.

So the lessons:

1) If you are embarking on a custom development project (such as a case management, for example) exhaust every possible option of using and customizing/modifying existing tools (Salesforce, CiviCRM, SugarCRM, other open source tools) before you begin to consider custom development from scratch.

2) If you have a budget of less than $100,000, go back, and stay, at step 1. I know this is high, but I’m serious. Obviously, simpler projects won’t need a budget of this sort. But simpler projects generally don’t need custom databases.

3) If you’ve got the cash to spend, and have exhausted all other options, when choosing a vendor, make sure the vendor you choose has UE expertise on hand. Look at other custom database work they’ve done. Dig in. Make sure it has the ease of user experience that you are expecting.

4) Remember the mantra: the easier it is to use, the more expensive it is to build.

Tagged as: , , ,

{ 3 comments }

Drupal 7

by Pearlbear on March 16, 2010

I’ve been doing a bit of playing around with Drupal 7 in my copious spare time (not a whole lot of that!) I’ve also been keeping track, a bit of how the development process is going, and what things will look like. One thing to say – it feels like as big an improvement as Drupal 6 was to Drupal 5.

Of course, mostly, Drupal is only as good as it’s contributed modules (that’s a bit more of a stretch, now, because many of the key contributed modules, like CCK, are now in core Drupal.) So when folks like us, who build sites that depend on Drupal 7 can start using it is a bit up in the air, although there is a movement to get many modules ready for Drupal 7 at it’s release. But some may well not make it. We’re guessing that we’ll start building production sites in Drupal 7 starting in late summer, early fall, depending on requirements.

A note: the standard process for deprecation of old Drupal versions is that when a new version of core comes out, the one two versions back stops being officially supported. So Drupal 5 will no longer get security updates and the like. Already, many module developers have stopped supporting versions of their modules that work on Drupal 5. (The salesforce module maintainers recently made that decision, as have others.) So certainly a site running Drupal 5 won’t stop working, but it will become vulnerable without security updates to core or modules, and it will get increasingly difficult to maintain and add features to. So it might be a good idea to budget the time and money to upgrade as soon as possible if you are on Drupal 5. If you are on Drupal 6, you’ve got a while yet, but Drupal 7 certainly has some great advantages, particularly in user experience, to look at.

Tagged as: , ,

Same crap, different day

by Pearlbear on November 9, 2009

I’m warning you – this is snarky.

I was only vaguely following the brou-ha-ha over Causes leaving Myspace. Only vaguely because I don’t really keep close track of the goings on in the Social Networking space: it’s not my passion. I use them a lot, both for work as well as for personal use. I know they are becoming an increasingly important tool for nonprofits in communicating with their constituents, and so I do keep them in my peripheral vision, for sure.

Anyway, in reading the varied reactions to this news, I had to just sigh, and then get annoyed. Sigh because of what feels to me to be the wasted energy that the nonprofit sector has spent over many years, using, hawking, and supporting proprietary tools and companies. Annoyed because it seems the nptech community hasn’t figured this out, even being hit over the head with this over, and over, and over again.

Make no mistake about it – Causes is a for profit company, and they are making what is, I’d bet, a decision based entirely on economics. If you’ve read any of the gloomy news from Silicon Valley, this is just the beginning. Social ventures will not be immune to the blowing winds of economic distress.

If we keep building our nonprofit toolsets on proprietary software and for-profit web services, even if they are free (for now) we are going to be bit by this over and over again. The only way we’re going to get out of this cycle is to channel this energy and resources into open software (including “open” source apps for proprietary web services), open standards, and open networks – things no one can take away.

I love to write blog entries about successful open source efforts – like CiviCRM, or the amazing stuff people are doing in the mobile space. Writing blog entries about for-profit web vendors that make economic decisions that hurt nonprofits because we depend on them too much is just not fun.

Tagged as: , , ,

{ 4 comments }

Open Mobile Camp report

by Pearlbear on October 25, 2009

Yesterday, I spent the day in Manhattan, at the UNICEF building, with a bunch of folks passionate about the technology in mobile phones, and the ways to use that technology for good. I’ve been a very long time cell phone user (had one since 1998), but I haven’t been involved in implementing a mobile system for an organization, so I had a lot to learn.

The place to find reports on what happend is on the wiki. Also, check out the twitter stream for the #omc09 hashtag.

I was especially interested in the issue of mobile data collection. (I was so interested, I facilitated a session.) And, even more specifically, I’m interested in how to leverage CiviCRM and mobile devices for a range of interesting applications. There are a number of ways to get data from mobile phones into a CRM – and all have advantages and disadvantages, depending on a lot of things.

  • Globally, what you can basically depend on is SMS. Smartphones haven’t made it into most of the developing world, nor have 3G networks. So how do you get SMS data into a database system like CiviCRM? You need an SMS gateway, and systems such as RapidSMS to gather data
  • Use J2ME to write applications for mobile phones, and send the data via SMS to a central database.
  • A tool such as EpiCollect, which is an Android app.
  • A slimmed-down, simplified webform to be used on mobile browsers.

One thing that would facilitate this would be a more robust API system in CiviCRM – access to the data via REST or JSON, which would allow CiviCRM to talk with some of the tools out there like Mesh4X.

I learned a ton. Thanks to MobileActive.org and the Open Mobile Consortium for a fabulous event.

Tagged as: , , , ,

{ 3 comments }

Newly discovered project management tool: Redmine

by Pearlbear on July 2, 2009

Any consulting shop that does significant amounts of implementation and development (as we do) needs a project management and ticketing tool. Basecamp seems to be a standard that many people have reached for. We were using Intervals for a while, which is really a fabulous tool if you do a lot of hourly consulting. We also have been using Google spreadsheets for some elements of project management.

All tools have their strengths and weaknesses. And, in addition, the best tool does nothing without good human project management skills using it. As a shop that practices Agile development (we use an adaptation of scrum methodology that seems to work for a shop that does multiple projects with small teams,) finding a good tool that facilitates instead of hobbles Agile was critical for us.

We found, and have chosen to use Redmine for our project management/ticketing system. You can think of it as a multi-project version of Trac, which is a fabulous ticketing/wiki system that we were initially going to go with. Redmine has the elements of Trac that we liked, with the added ability to track multiple projects. Like Basecamp, Redmine has document storage and messaging systems. It doesn’t have milestones per se, but it does allow you to see tasks in calendar and Gantt views, which is very helpful. Unlike Basecamp, you can add custom fields to tickets, users and other features. Having spent many hours in Basecamp, I actually like Redmine much better. It does even do time tracking, which we won’t use, but is nice to know is there. And the wiki is nice. Basecamp’s Writeboards seem so much more like an add on than integrated.

It’s a Ruby on Rails application, and that was actually kind of fun to finally get to install and play with RoR a tiny bit. And it’s great that it’s free and open source. Although that wasn’t an absolute requirement for us, it is most definitely a plus, given so much of our work is implementing open source web tools. And it’s nice to save a few bucks per month.

Tagged as: , , ,

{ 7 comments }

← Previous Entries

Next Entries →