Tag Archives: opensource

IT at the University of Cincinnati

On Wednesday evening, I had the great privilege of being invited to the University of Cincinnati to attend the basketball game against Notre Dame, in the President’s box at the arena. In attendance, in addition to the President himself, were various people from, or connected with, the IT (Information Technology) program at the University of Cincinnati.

The IT program covers a broad range of computer technology related fields, and has specializations in networking, databases, programming, and various other areas. Students are exposed to a wide variety of computing platforms, so that they don’t get into a job interview situation and have to admit that they only have training on Microsoft products. Or only Linux products, for that matter. A breadth of experience is pure gold in an interview situation.

Hazem Said, the new head of that department, was my kind host at the game, and we talked about a variety of ways that Open Source can feature in an IT curriculum. I’m really excited about the kinds of things that are in the future for this program. We talked about having students participate in healthy, mature Open Source projects as part of their training. This would give them experience not only in software programming, but also in project management, cross-cultural communication, customer support, and marketing, among other things.

When I was in college – which wasn’t so very long ago – there were some computer classes, which were mostly programming, but nothing that covered the real discipline of Information Technology in the way that I saw on Wednesday. It gives me a great deal of hope for the next generation of IT professionals that come of this program, and other programs like it around the world.

By the way, if you’re ever invited to a basketball game by the head of a University department, do a little research, and don’t wear a shirt with the other team’s color. (Really, it was an honest mistake!)

Open Source and The Cloud

I had something of an epiphany in the shower this morning. I discovered that I actually agreed with Bradley Kuhn about something.

TLDR: Is “the cloud” a threat to Open Source? I stopped working on an Open Source calendaring project because of Google Calendars.

Several months ago I attended (part of) a talk by Bradley about how The Cloud (whatever that is) is a threat to Free Software. (Yes, I know what The Cloud is. Snarky remark in reference to all the different things The Cloud might mean to various people. See Simon Wardley’s wonderful talk about what the cloud is.)

His reasons struck me as so outside of my way of thinking about software that I ended up leaving the talk. Oh, also, Skippy wanted to go to lunch, and that sounded like a lot more fun. Nothing personal, Bradley. He was talking about how something like Google Calendar (actually his example was GMail, but hold on a minute) was a threat to Free Software because the code, even though it’s in Javascript and right there in front of you, can’t really be inspected (ie, you can’t learn from it) because it’s hugely obfuscated. Also, you can’t see the back end. So here’s a service you can use for “free”, but it’s not Free, because it’s in chains, metaphorically speaking.

Then, this morning, I was thinking about why people are involved in Free/Open Source software, but also why they stop being involved, and I realized something.

I used to have a web-based calendar thingy. It was written in Perl, and it was really very cool. In fact, it not only started my passion for Open Source (it was the first thing I ever had on CPAN, and it was the first software that I ever wrote which was featured in a book!) it also paid my mortgage for a few years. I used to write calendaring applications for the General Motors Desert Proving Grounds in Mesa, Arizona. Although that plant is long closed, their scheduling ran on my software. If you wanted to schedule a test on the dust track (tests a vehicles various rubber seals to make sure they keep out dust, as well as handling in those conditions) you used the web-based scheduling application, called D.U.S.T. (I forget what it stands for – Dusttrack Usage Scheduling Tool or something) and scheduled it. This worked better than grubby bits of paper, because it didn’t get lost, and you always could get to it without walking down the hallway.

Also, when I was at Databeam, back in the late 90s, I wrote a similar application for scheduling conference rooms (clever name: Conference Rooms). I went up to the front desk one day and stole the conference room scheduling book and hid it, forcing everyone to use the online scheduling app. Strangely, it worked, and I didn’t get fired.

Then, I got involved in a project called Reefknot, which was an implementation of various international calendaring standards, in Perl. That was humming along nicely. And I had a dozen different calendar modules on CPAN.

By the way, in case you don’t know, calendaring is hard. Sure, it looks easy, but then you get into things like “every other Monday at 10am, except during company vacations.” Or possibly “the last day of each month.” Think for a little while about how you’d implement that, and your brain will start to melt just a little. “every monday” suggests a simple solution, but as soon as you start having to deal with exceptions, things get very very complicated. And what with different length months and leap years … and don’t even get me started on time zones. *shudder*

Anyways, then something called Google Calendar came along. It worked with all of the various calendaring applications. It did the various calendaring specifications, including the long-elusive CalDav. We were all very excited in the calendaring community, but then an odd thing happened. People stopped working on calendaring stuff. Because, you know, it’s already done.

So, I stopped working on an Open Source project because there was an implementation in the cloud. (ie, online somewhere.)

So, was Bradley right? Did Google Calendar kill the Reefknot project specifically because it’s closed source? Yes, in a sense. I don’t believe, as the FSF does, that closed source is intrinsically immoral. But there’s a direct correlation between the projects I no longer work on, and great cloud based implementations of the same functionality, where I don’t have access to the source to participate.

Furthermore, as my interaction with software is increasingly via a browser, and not via running software on my own computer, I have less and less incentive – and ability – to tinker with those things.

Now, I’m weird, I still run several of my own servers. Granted, those servers are “in the cloud”, meaning that I have no idea where they are physically located. But I have root on them. I build software from source on them, and tinker with that source from time to time. I tinker with the source code of my blog, even though there’s a good blogging platform “in the cloud”, but I also have several blogs on Blogger, simply because it’s simple and I don’t want to monkey with it.

So, although I disagree with Bradley’s philosophically, I find that he may be completely right for more pragmatic reasons.

But at the same time, Open Source has a whole new rebirth of late, and there continue to be ever more exciting projects out there. I’m much more concerned about my kids, and what they will find to hack on. My son is a hacker. He likes to build stuff, take stuff apart, break it and fix it, figure out how it works. I don’t know if I’m doing an adequate job of encouraging this. I really need to get him a subscription to Make magazine. I wonder, however, when he gets a little older, if he’ll be interested in programming. I think he’d be really good at it, but it would be a great shame if the removal of applications to The Cloud also results in a lack of opportunities to hack on code.

Write a better FM

I’ve been delighted to see the “Write a better FM” meme that’s been spreading slowly through various blogs. I understand that I’m to attribute this to Kathy, but I’ve been saying this for years. It’s not sufficient to tell people to Read The Fine Manual, you have to actually listen to the questions that they are asking, and make sure that TFM actually answers them. And, if it doesn’t, then make it better.

This is sometimes as easy as it sounds, but usually isn’t, for reasons that are often non-obvious to people that are in a place to make the world better.

It’s too hard to make the docs better. Those of us who are involved in documentation need to:

  • make it easier for folks to tell us what’s broken
  • be less defensive when they suggest ways to fix it
  • clearly identify our audience and listen to their problems
  • provide clear, correct, efficient ways for them to achieve their goals, rather than telling them that they have the wrong goals

If we don’t, what happens is that a thousand stinkweeds bloom. I’m discovering this the hard way with mod_rewrite. Because the documentation for mod_rewrite is so intimidating, and folks don’t know how to contribute changes to it, instead they write hundreds of HowTos and tutorials and recipes and rants about how to do things in mod_rewrite. These articles are, for the most part, wrong. The ones that work, often do so by sheer chance, and are prone to break if attempted elsewhere. But desperate users take these tutorials, hack on them until they mostly work, and they pass their hard-won ignorance on to other folks.

We could have prevented this, but we chose, by our inaction, not to do so. The problem is *much* harder to fix than it would have been to prevent.

I’m thinking about better ways to allow end-users to tell us that the docs suck, or to suggest improvements. I’ve never been a fan of the PHP methodology, which I have at times called “Scripture With Commentary”, primarily because so much of the commentary is crap. However, it gets the job done, and seems to be the best of the bad. I’d love to hear your suggestions of better ways to collect user feedback, and, perhaps more importantly, incorporate it into the end product.

Writing Documentation

Someone (and I now can’t remember who – I think it was Philip Olson) pointed me to Writing Open Source this week, and I’ve been somewhat fixated on it since.

I’ve been writing technical documentation for more than a decade now. 12 years sounds about right. Let’s go with that. I’ve been told I’m good at it, so I keep doing it.

I’ll let you in on a little secret. I don’t tell just anybody this, because they think I’m a freak. I actually enjoy writing documentation. I enjoy figuring out how things work, and then writing about it so that other people don’t have to figure it out. I enjoy catching the first glimmer of the spark of understanding when someone reads what I wrote and gets it for the first time. I love it when people say “Oh! I didn’t realize it was that easy!” and “Why did it seem so complicated before?”

There are precious few places that do documentation well. There’s a number of places where Open Source documentation, and software support in general, typically falls down.

* Tell the user that they’re an idiot, and probably too dumb to use this software. This is done in a variety of ways, and is often abbreviated RTFM, but TFM is often insufficient.
* Pretend that the end-user cares about the architecture of your software. They don’t. They just want to get their job done.
* Fails to distinguish between end-user and developer documentation, and, if there is a distinction, the path from one to the other is left as an exercise to the reader
* Refuses to consider the interrelationship with related technologies, and continually tells the user that “that’s a problem with ProductB” rather than giving them the support that we’re qualified to give.

And many, many others.

As I looked at this website, I became more and more persuaded that perhaps I could help in the effort to write a guide of how to write Open Source documentation – not from the perspective of whether to use passive voice or not, but from the perspective of identifying with your audience and answering the questions that they’re actually asking, not the ones that you feel that they should be asking.

On a related note, during a recent conversation on IRC I suddenly realized that I’ve been working programming jobs all these years because I haven’t been able to find a position that’ll pay me to do what I really love – writing technical docs. I wonder where this realization will take me in coming years.