Posts Tagged ‘open source’

Build Things to Solve a User’s Problem

The company (or project) that figures out how to do this will win.

That’s what Matt Asay says on his CNet blog. What to know what he said that about? He said that open source projects need to:

determine what average users want and then to translate this into development plans

Asay says that Apple wins with users because it takes what users want and makes its engineers deliver it, while typical open source projects, made by engineers, are not often made to be used easily.

It’s one thing to create a cool app that can do wonderful things. But the user doesn’t want a cool app- he wants a solution to his problem. Thinking man Clayton Christensen expresses it this way: People that shop for drills don’t want a drill. They want a hole.

Solve their problem and solve it in a slick way. Then you’ll have a fan.

New? Don't forget to subscribe. Thanks for visiting!



Proprietary Tools Building Open Source

As I read Matt Asay’s blog post this morning on the use of proprietary tools in the advocacy of open source ones, I recognize that my foray into the Mac world changed me quite a bit. Almost from day one using a Mac I was shelling out money to get an app. They were, mostly, well-made and not very expensive overall. But that was after years of being a Red Hat then SuSE Linux user and being sworn to the cause of open source. I think, as Matt says of Mark Antony, that I have become a pragmatist.

I’ve mentioned before that Linux users should be willing to pay for software- even proprietary, closed-source software- for Linux. One problem at a time is a good way to think of it. A better way is this: if people are willing to buy software for Linux, what will be the result? There will be more and more Linux software vendors. And if there are more vendors, Linux becomes a more viable option for those still on the fence.

I use and love Linux. All day in Linux, I’m programming using the Komodo IDE- a proprietary script editor built on top of the Mozilla codebase. I love that too, and I don’t see the conflict. Yesterday, I bought the codecs pack from Fluendo. I love that it’s available. That said, I use the GIMP and Inkscape for all my graphics needs- even at my day job I insist on that. The fact is that there are free or open source alternatives for just about anything you can think of. If the value proposition is there, I will pay for a tool. But with how advanced Linux is, paying for an operating system is galling. Why do people buy Windows®? Because it’s so good? No. They buy it because the apps they use run on Windows®. Buying Windows® has become merely a tax on using apps they are used to. How sad.

Let’s be pragmatic. Pick your battles. Let’s make Linux the priority.



Who Names These Projects Anyway?

Too often, open source programs have bizarre, unhelpful names. This needs to change, at least for desktop applications, for Linux to really take off in that market.
  For all my love for Linux, software names in Linux are probably the most cryptic, arcane names possible. To understand them, you need to have seen most TV shows and sci-fi movies in the last thirty years. Preferrably, these should be the ones that no one else saw. You must also have a large zoological encyclopedia on your bookshelf. At the time of this writing, the site where the newest open source software is announced, freshmeat.net, had listed the following new releases (this was a couple years ago now):

  • Kile beta 1.0
  • JDHCPSim 1.1
  • JavaGuard 1.0b1
  • Cerberus Helpdesk 1.1.5
  • TyGeMo 0.2.0
  • Gibraltar Firewall 0.99.3a
  • archmbox 3.0.2
  • Star Voyager 0.4.0
  • KDevelop 2.1
  • OpenVPN 1.1.0
  • SPIKE 2.1
  • php_jh_pdf 1.1.0
  • lintad 0.0.3
  • KDE 3.0
  • uClibc 0.9.11
  • samhain 1.4.7
  • phpTest 0.5.0
  • HylaFax 4.1.1
  • JBoss 2.4.5
  • phpmailer 1.60 (Stable)
  • wmmemload 0.1.2
  • Rolodap 1.0
  • SmartTAN 0.1.1
  • userinfo 1.6 (Stable)
  • Sidewinder Forcefeedback 2 driver 04102002

Look at those names. How many are readily understandable to a non-geek? Hmmm. Another thing is the version numbers. I’m not saying that they shouldn’t be accurate. These numbers reflect exactly where the program is in its development. The difference between these and commercial programs is that commercial programs usually have announcements of a new version on two occasions:

  1. there has been a recall or security patch or
  2. they have hit another whole number version (like 2 or 3).

To be fair, freshmeat is a site where you announce the “freshest” release. I think it’s partly because to me, and I thus assume it to be true of all geeks, it’s fun to install new software and try it out. And this way, you can have the very latest of everything. Many open source software are what you’d call server applications. They are really for the backend or administration of a website or network. And since those that care for those areas are geeks, it’s okay for them to be a little more exact.

Open source names often have puns (notice HylaFax – Halifax, Canada). They also often incorporate a bizarre word (samhain) or the name of an animal. Common names of animals as well as genus and species names are fair game, too. For non-geeks (and even geeks), this makes it necessary to read the description of everything. You’ll notice in the list that some kind programmers have put a helpful indicator in the name of their program. If it starts (or ends) with “php” it probably has something to do with the PHP server programming language, whereas a “j” would usually indicate a problem based in some way on the Java programming language. Those names with a capital “K” usually are designed for use with the KDE, the K Desktop Environment. Programs that start with a “g” are likewise designed for the Gnome desktop. “Gnome” itself is a bizarre mixture of fancy, puns, and acronyms. It is actually an acronym for GNU Object Model Environment. GNU in turn stands for GNU Not Unix, itself a programming joke because this acronym causes what’s called an infinite loop- the acronym repeats itself forever. This is amusing to me, but I’m a programmer. I think most people would find it odd. Gnome, however, is a fine name, but I don’t like to think of as an acronym. I like it anyway.

When applications are written, they should be better named. It’s not that the name needs to be descriptive, but it should be a name perhaps combined with an explanation. Mystery. Don’t make users have to deal with that. Next week we’ll talk about good names. The surprise users feel about your app shouldn’t be that they would never have guessed that an app with this name would do that- your app should take their expectations and exceed them with features that make their lives easy.



Be Willing to Pay

I’ve been listening this morning to a linux podcast and one of the participants mentioned how he can’t imagine paying for Linux or entering a serial for software he’s installing on Linux. This is a bad attitude.

Look at two of the most recognizable open source programs- Firefox and OpenOffice. Besides being open source, anything in common? Yeah- they both started life in the open source community as established, full-featured products. The owners decided to take a commercial product and open source it.

I know it’s the not popular way to think here in the open source world, but I’m quite willing to pay for software that is a good value. I reject the idea of having to buy a product to open a file, but if your software is great and helps me out I will pay for it. And I will tell others to. (Although if it has some crazy limitations like a limit on the number of times you can install it on a different computer, Adobe, I won’t go for that.)

The more app developers we can welcome to the Linux community the better. As time goes by maybe they will open source their product. Maybe they won’t. But more quality apps for Linux is a good thing. Be willing to pay.



Improving Apps: Some hints, tips, and thoughts on marketing an app for Linux.

More

Pure Linux: How I use Linux 100% of the time.

More