Getting Started guide for Lubuntu novices

Just thought I’d share the Getting Started guide that grew from my periodic use of Lubuntu to make old PCs useful to the needy.

It’s on GitHub and you can also view it online though the WebODF renderer doesn’t yet seem to obey instructions to stretch tables to fill a page’s width or span cells across rows.

Posted in Geek Stuff | Leave a comment

…sort of like DxDiag for Linux

TL;DR: This script collects hardware and OS info for reporting bugs in Linux games because, on Linux, the functionality of DxDiag is split up across several different tools.

The Humble Indie Bundle 6 just came out and, wanting Torchlight, I bought it. Now, like any early adopter, I did run into a bug (it’s already been fixed). This isn’t about that, though.

When I read the README.linux file, it asked me to gather a bunch of diagnostic information and, being the distractible geek I am, I ended up writing a script to automate it.

…I went above and beyond the call and expanded it into something more like a console version of the Windows DxDiag utility. (Which will also open a terminal for you if you double-click it) So, if you ever need to submit a bug report for a Linux game, run this script. It’ll gather all your hardware and system configuration in one easy-to-read, easy-to-attach file.

Note: I’m still working on figuring out what kind of data I should collect for debugging audio and input issues. If you have any suggestions, please leave a comment.

In case you don’t feel like scrolling past the embed or you’re not used to working with embeds from GitHub Gists, here’s the direct download link.

Posted in Geek Stuff | Leave a comment

Questions to ask when marketing software and services

After writing what must be my third or fourth e-mail offering advice to an online service whose marketing completely missed the mark with me, I started to notice that I was touching on the same set of points.

Again and again, startups seemed to miss that, despite their differing goals and shorter attention span, smart users will act like investors. As such, it’s essential to address, at minimum, these concerns:

  1. Financial Viability: Can potential users clearly see how you intend to earn enough money to still be around and paying the bills 5 months, years, or decades from now?
  2. Clear Pricing: If your free offering is more than just a trial period or if you offer free accounts to certain groups (eg. non-profits, open-source projects, etc.), does the landing page make that clear? Is your offering only free until the beta period ends? Try to, at the very least, give an estimate how much it will eventually cost.
  3. Clear Offerings: How easy is it for users to compare your different plans? …especially any free offering you may have versus your paid offerings? Don’t get artsy here. Put a table/chart somewhere and, if it’s not on your landing page, follow convention and put a link named “Pricing” or “Plans” in your header.
  4. Clearly Stated Audience: Potential users don’t want to waste their time learning about your features if your service is too expensive or won’t scale up to meet their needs. Make information on your plans clear and easy to find.

Now, when I write these e-mails, I tend to write them to people who strongly believe that their code is a trade secret, but when I’m actually choosing software and services for myself, there are two questions I ask (which are far more important to me) which marketers should have honest responses to:

  • DataPortability: How hard would it be for me to export my data and take my business elsewhere if I grow disaffected?
  • Open Source: Can I run and customize a copy of the software myself to meet my requirements for privacy/security/reliability/longevity/features? Can someone else pick up the pieces if the service provider goes bankrupt or loses interest in the product?

All in all, it boils down to two very subjective questions that people try to answer when deciding to invest their time, energy, or money:

  • Do I understand what I’m getting?
  • Will any changes without my consent be to my detriment?

Update: For end users, this How Do They Make Money? explorer helps to streamline some of these questions for the more popular sites out there.

Posted in Web Wandering & Opinion | 1 Comment

How to use things like Fat-Free Framework with “php -S”

Having grown very used commands like these, nobody was more eager than I when PHP 5.4 introduced its own no-setup development server.

  • python manage.py runserver (Django)
  • paster serve --reload (Pylons)
  • nodemon (NodeMon for Node.js)
  • jekyll --auto --server (Jekyll, used by GitHub Pages)

However, in typical PHP fashion, there’s some assembly required and you’ll probably need code from either the comments or somebody’s blog to get it to behave the way you’d expect it to by default.

So, without further ado, here is what I came up with to get the basic “excise index.php from the URLs and pass static files through” behaviour most people use .htaccess for.

(There is a command-line option for this sort of behaviour, but it doesn’t match the behaviour of the net’s most ubiquitous mod_rewrite snippet.)

It’s been tested under Fat-Free Framework 2.0.6 through 2.0.12 and, if there are any incompatibilities with other frameworks or PHP applications, they should be minor.

Posted in Geek Stuff | 1 Comment

A Quick “Contact Me” Fix

Apparently, the CGI script powering my mail form slipped through the cracks when I was setting up health monitoring for this site and had been giving error 500 for an unknown period of time.

It’s now fixed and I’ve rewritten it in PHP so that, hopefully, if such a problem occurs again, the blog will have died too and I’ll notice immediately. I also added suggestions for alternate contact methods on the form page.

Finally, feel free to use the comments thread on this page to report trouble.

Posted in Site Updates | Leave a comment

GitHub vs. BitBucket: Shifting Value Propositions

It used to be that GitHub vs. BitBucket was a no-brainer. GitHub was sleek, featureful, popular, and supported git, the godsend.

BitBucket was clunky, buggy, comparatively little-known, and required you to use that hg thing with the annoying workflow.

However, as time has gone on and Atlassian has continued to work on BitBucket, things seem to be shifting in BitBucket’s favor. BitBucket has added support for git, offers private repositories in their free tier, and continues to make minor improvements every now and then, while GitHub seems to be backsliding.

Oh, GitHub still looks nicer by a mile and continues to improve on that front, but what you can do with it and how you communicate are backsliding (and communication is the whole point of the thing). For example, in recent months, GitHub has:

Killed off the private messaging system

GitHub claims that, by killing off their private messaging system, they’re serving us better by giving us one less inbox to manage… yet I still obsessively go into GitHub every few days to flush out the pointless “GitHub Pages built successfully” messages and duplicates of bug notifications that pile up in the “notifications” inbox.

(And the only button that applies to everything is “mark as read”, so I manually have to click every single entry to delete them… including a page reload after every ten clicks.)

Couldn’t they just have ditched both web inboxes, kept the PM form, and forwarded all messages directly to my primary e-mail address for handling?

Forcing me to expose my e-mail address to the world if I want to be reachable and forcing me to abuse the issue tracker to communicate with like-minded individuals is so bass-ackwards that it makes SourceForge seem superior!

Update: GitHub now supports only receiving notifications via e-mail, but they still haven’t provided a replacement for the PM form’s old status as a spam-proof, guaranteed-to-be-there way to contact another user.

Started requiring that user.email actually be an e-mail

At first glance, this may seem reasonable… except that git itself doesn’t enforce that constraint and git is famous for not letting you rewrite old commits without breaking push/pull with everyone else’s branches.

What makes it even worse is that, since GitHub used to support it, who knows how much data was submitted which once was valid and now isn’t. Smart move, guys.

I don’t know about you, but I’d rather give up having my commits hyperlinked to my account (or, even better, just switch to BitBucket, which still allows arbitrary strings) than leave a genuine e-mail address lying around where every spambot in the world can find it.

I’ll be sticking with http://www.ssokolow.com/ContactMe as my commit ID’s “e-mail address”, thank you very much.

Replaced their blog comments with Twitter

As Christian Heilmann elaborated on, Twitter is not a discussion platform because its character limit kills nuance in discussion, it has no threading, and its structure makes it nearly impossible for anyone but the author of the blog post to gauge community reaction.

If I find news sites without comment systems unsatisfying and/or distasteful enough to avoid them, I’m not going to be very enthused about a “Web 2.0” code-hosting site that does the same with their public announcements. I don’t care whether it’s spin-doctoring or just laziness. (Again, if I wanted the latter, SourceForge has it in spades)

 So… BitBucket

So, these days, what exactly does BitBucket do wrong, aside from losing the network effects battle?

Surprisingly little from what I’ve been able to tell… they just made some bad choices in what they did wrong:

No GitHub Pages Competitor

Most of the time, when people host a project, they actually care about getting potential users interested in it. That means they need to host screenshots and logos and possibly even JavaScript demos so they can make a good first impression. It also means they probably want to give their project a memorable look and feel. Wikis, issue trackers, and repository browsers don’t do that.

I’m told BitBucket has support for a per-user Pages equivalent, but that’s not really a big help (It took me ages to find a use for GitHub’s per-user Pages support but I was using per-project pages from day 1) and it’s so under-documented that, despite looking for it, I spent months not knowing it existed. (BitBucket’s opportunity to be worse than SourceForge)

If I’m going to have to pay for site hosting anyway, I might as well just host my own git repository and bug tracker while I’m at it and gain more customization support.

Poor First Impression for Project Pages

With no equivalent to GitHub Pages, the full burden of making a good first impression falls to the project pages. Unfortunately, they are also in need of some TLC.

First, they still knock-off GitHub’s old theme, which now feels five years out of date. Not a good first impression to make when the projects you compete against for attention are probably hosted on GitHub.

Second, the default configuration for a project’s landing page shows off their most recent commits and their README file. The problem is, in my experience, there are three pieces of information, from most to least urgent, that I want to know when I visit a project’s landing page:

  1. What it’s about. (GitHub and BitBucket both get this right by showing the README.)
  2. What the license is. (Neither GitHub nor BitBucket support this explicitly, but GitHub’s overview page makes it trivial to see and click on the COPYING or LICENSE file.)
  3. What language the project is written in. (Same situation as the previous point.)
  4. How actively developed the project is. (GitHub didn’t used to show the most recent few commits on their overview page, but if the first three are satisfied well, then I have no problem with one click to check the commit log.)

Yes, you can configure your BitBucket repository to show the tree browser as the default, but then it doesn’t display the README, which is even worse.

So where does this leave us?

For now, I’ll continue to use GitHub… maybe with a public e-mail like use.the.mail.form at ssokolow.com which I can make valid only long enough for GitHub to accept it.

However, they’re on very thin ice and, hopefully, BitBucket will wake up, seize this opportunity, and give GitHub enough competition to restore progressive (rather than regressive) innovation to code-hosting sites.

(Seriously, Google Code? You thought it was helpful to remove the project activity overview when the majority of projects on established sites are dormant and possibly buggy?)

Update: While our needs differ on things like the importance of a valid e-mail address, Linus Torvalds also makes good points on GitHub’s shortcomings. Not sure how BitBucket compares though. Probably equally poorly. (A little something that came to my attention via Planet Mozilla)

Posted in Web Wandering & Opinion | 4 Comments

Open Source for MBAs: A Primer

If you’re neither a scientist, nor active in the open-source community, it can be difficult to properly understand why people write open-source software. Why would people just give away the products of so much hard work?

I fully understand why one would be wary of a free product with no apparent profit model. After all, it’s only proper caution to check for Trojans when receiving a horse.

The trick with open-source software is to think about it in different terms. Traditionally, if you needed a piece of software or documentation or some other product that can be copied or photocopied, you had two options:

  1. You could find something that met your needs and then pay per-seat or per-site for a version someone else had written.
  2. You could hire someone to create your own version from scratch.

Paying for an existing solution can get expensive if you need a lot of copies, but writing your own version from scratch usually costs even more.

Using someone else’s solution makes you dependant on them for fixing bugs and writing new features, but writing and maintaining your own draws resources away from competing in whatever markets you occupy.

Open-source provides a third option with a slightly different payment structure. Instead of money, open-source vendors want you to pay for their software in externalities and, if they’re lucky, maybe you’ll chip in with a bug fix or a new feature to sweeten the pot for everyone.

One popular way is to set up a business to sell support contracts to businesses using the software in mission-critical places… often at prices lower than companies like Oracle and Microsoft who know they have you by the unmentionables.

Here are a few other examples of externalities that commonly motivate people to give away their code:

  1. If you write a piece of software to solve your own problems, up to 90% of the time and money you spend on it over its lifetime can be spent on maintenance. If it’s not the “secret sauce” that makes your business competitive, then it’s just an expense and sharing the code with the world is a non-taxable payment for good publicity and an air of progressiveness in the eyes of potential employees. It may also reduce the amount of money spent if someone else fixes a bug and submits the fix back to you.
  2. On a more individual level, we all like to be acknowledged. Contributing to an established open-source project or founding one that becomes popular is one of the quickest and easiest ways to build a favourable reputation among your peers, expand your resumé, and gain portfolio pieces that aren’t crippled by restrictive copyright terms.
  3. Why involve the overhead of charging for your software, collecting sales tax, and then paying the money to advertising agencies to set up “viral marketing” campaigns, when giving it away for free cuts out the middle-men and takes you straight to “If people use your software and like it, then they will tell their friends and co-workers.” (Genuine word-of-mouth advertising is also more sincere and, therefore, more lasting)
  4. If you run a successful open-source project, nothing makes a better business card for your support services than letting potential customers use and customize your software for low-risk applications for free. Even big companies like Microsoft often use a variation on this technique when they allow a certain amount of illegal copying in order to get individuals hooked on and familiar with their products. Open-source just introduces honesty and a better ethical and moral framework to the technique.
  5. If you give away your software for free, like many companies do with the “non-Pro” versions of their tools, people are dependant on you for any changes they need. Fixing bugs, adding features, etc. That’s a heavy burden to carry and, if you fall behind, it’s bad for your reputation. If you release the source code, you are granting skilled users and companies the ability to fix problems they encounter, and to then offer the fix to everyone without putting more pressure on you.

Just because open-source developers and vendors aren’t getting paid for their software in money doesn’t mean they aren’t getting paid. To an open-source developer, their software is their business card, a pride-worthy piece of art they want to share with the world, a tool they crafted to fix their own problems, a foot in the door for related products and services, and the seed for a group of like-minded people to collaborate with.

Also, while it doesn’t necessarily affect the bottom line, programmers often have a deep understanding of how easy it is to copy software, which makes one’s job more satisfying if they know they’re being paid for their time (which is a scarce commodity) rather than copies of their software (which are vanishingly cheap to make).

As a final acknowledgement, if you are considering sharing software that you’ve written yourself, there are a few hidden gotchas to getting a community to form and they all boil down to whether or not potential participants feel empowered. Here are the basic rules:

  • Use an un-modified version of a popular license that people know and understand, like the Apache license or the GNU GPL or LGPL licenses. Legalese is scary and programmers aren’t lawyers.
  • Write clear instructions on how to compile a working program from your code. Make sure they actually work on a freshly installed machine. (I use VirtualBox for this)
  • Provide an easy-to-use system for filing bug reports and feature requests, and offering up contributions. There are many tools for this as well as sites which will host your project for free. (I suggest GitHub or BitBucket)
  • Strive to make participants feel that their concerns are being listened to.

In short, there needs to be a smooth learning curve that can take people from “just wandered in” all the way up to “respected participant”.

Posted in Geek Stuff | 3 Comments