Monthly Archives: August 2014

Editorial, Programming, Software

Add-ons, A Blessing Or Curse?

Leave a comment

Software add-ons, a.k.a. plug-ins or extensions, offer the promise of more capability beyond the core package. Though the cost for such expandability isn’t free. In my experience they can be both a blessing and a curse.

Add-ons for projects like the Firefox browser and WordPress have benefited both the users and makers. Doing so keeps the core lighter and simpler and without sacrificing the flexibility and customization that have made them so popular. For example, paranoid browser users like myself can supplement built-in features with things like Disconnect or NotScripts.

Once I administered a website using Drupal’s content platform. It was a lot of fun to browse their modules section looking for things that would help enhance the site. However, with Drupal 5 and 6 upgrading meant disabling those modules first, installing the update, then re-enabling them. And some weren’t compatible or didn’t update themselves properly. It was also a manual process, even with the Drush tool helping me along the way.

Drupal began encouraging module authors to offer guarantees they would support the next major version. But I had already been burned. Newer versions may have improved the situation, but a friend and I moved the site to another platform instead.

Add-on advantages typically include:

  • Expandability where it’s otherwise impractical (because of the license, platform, etc.)
  • Lighter, simpler core
  • Customization apart from a vendor’s built-in capabilities
  • Allows the core to be free and open while premium features are sold separately

Add-on disadvantages often include:

  • Installing, upgrading may be more complex than without
  • Add-on interfaces (for programmers or end-users) can be limiting and awkward
  • Maintenance of add-ons may lag far behind the core, hindering core upgrades
  • Development costs to produce and maintain add-on interfaces and ecosystems
  • Additional security risks as the number of vendors involved and attack surface increase

One of the most famous add-ons is Adobe Flash Player. Flash provided a boon to browser-based games which only recently is being overtaken by newer built-in browser capabilities like more advanced Javascript and HTML5 features. It has also provided media playback for video and audio. Yet I have found it to be buggy, awkward, and inaccessible at times.

As a software producer the ability to build upon existing platforms helps avoid building from scratch. Often it’s useful as a means to prototype ideas or experiment. Though, the risk of platform upgrades breaking one’s work is ever present. On one project I found myself spending about 2-4 hours each week keeping some add-ons up-to-date with core changes coming from upstream.

Looking at the big picture my experience with add-on’s has been generally positive. They have allowed me to tailor software for according to personal preferences and needs; often far outside the intent of the original vendor. While the disadvantages have discouraged me from using one platform, they aren’t enough to outweigh the benefits.

How about you? What’s your experience with add-ons, plug-ins, modules, and the like? Please consider commenting.

Editorial, Software

Why I Regret Making Free And Open Source Software

Leave a comment

Looking back on the time and energy I poured into making free software leaves me with regret. From the whole experience I gained perhaps some minor notoriety, a few entertaining IRC chats, and the realization that ‘free’ doesn’t pay for itself.

Being a teen who loved game technology and Star Wars, I spent thousands of hours combining them to contribute to a game modification known as Star Wars Quake: The Call Of The Force. While I enjoyed the work at the time, it became obvious looking back that I can never directly profit from it because:

  1. It’s already been released for free
  2. Trademarks belong to someone else

Others have successfully turned their game-modding hobbies into careers or products. I wish them, and those seeking the same path, all the best.

Regardless, I don’t regret making mods. What I regret most is spending so much time doing work with little or no hope of reimbursement. Ten to twenty hours a week over five years is a lot of time. Had it not been so much time and effort, led to a job, or if it could have been sold then I’d feel differently. So my advice to would-be producers/modders is to be very careful before working with another company’s property and consider the consequences before releasing any of your work at no cost.

As a user of software, the abundance of free software is undeniably a win: not only can it provide value at no cost, but there are often several, zero-cost solutions. And it’s increasing obvious that free and open software is gaining serious popularity. Most troubling to me are the all-software-should-be-free expectations of users and the anti-proprietary culture demonizing producers who choose a different path. Despite making a living producing proprietary software I too found myself frowning upon non-free or non-open software at times.

Cases can, and have, been made for why open and/or free is the best way for some endeavors; such as non-profits or governments. Yet there is still value to consumers in paying for the use or a copy of software instead of only it’s initial development. For example, I personally find paid editions of software more pleasant than the minefield of ads and toolbars increasing common in otherwise free software.

There is also plenty of room for compromise. A few possible hybrid approaches include:

  • Vendors could agree to release source code when a product reaches end-of-life
  • Consumers could opt to pay a premium price for editions with source included
  • Source could be provided upon request, with or without redistribution rights

The trend seems to be that software producers feel pressure to move from standalone products to providing services. Anecdotal evidence also indicates that free and open isn’t a the be-all-end-all solution: SugarCRM moved to closed source, OwnCloud pushes paid editions and services, Google’s MyTracks has stopped releasing sources, and Google has abandoned the open-source editions of many stock Android applications. Nicholas Carr does a reasonable job summing up the tension programmers experience as the free and open software movements march onward. You can also find out more about the labor issues from Ashe Dryden’s post.

What do you think? If you’ve something to share please consider leaving a comment.

Ecology, Editorial, Start-up

Maximum Sustainable Business

Leave a comment

What upper bounds limit, or should limit, the size or scope of a business? Developing the lower boundary of a product is already a proven strategy for launching products. And since the idea of a minimum viable business has already been addressed, let’s consider the upper bound.

Physical limits impose some basic restrictions such as the amount of arable land, number of possible consumers, or the amount of money in a market. Some may change over time while others may be fixed. For example, if Canada’s economy had only 2 trillion units of currency available then it’s impossible for a company to exceed that value in Canada; at least until the economy grows.

Legal restrictions also exist in many markets. Cuba’s Agrarian Reform Law limits farm sizes to protect the workers. In the US there are several anti-trust laws to prevent abuse and promote competition among businesses. Whatever one’s view of government’s place in the economy, the intention is clearly to balance the interests of consumers, producers, and employees.

Having worked at larger and smaller companies I’ve seen the advantages of scale: efficient use of (some) resources like instructors’ time, fewer workers needed for administration, and spreading risk. Smaller scales also have their pros; such as more personal management, less bureaucracy, and often a faster path to promotion. However, I think the disadvantages of larger businesses outweigh the benefits. Some cons I’ve witnessed include compensation not tied to performance (discouraging working harder or even at all), reluctance to change, more careless about environmental effects, and a tendency towards anti-competitive behavior.

Sustainability in the long term is another important goal. If a company wants to exist forever then environmental impact becomes a priority. Thankfully even some larger companies are becoming more aware of the issue.

If all businesses considered the human and environmental factors as heavily as financial ones then perhaps more would choose to limit their size. If government regulation more aggressively addressed anti-competitive concerns and taxation encouraged sustainable, small business then I believe it would also be more humane. As machines are increasingly competing with people for jobs wouldn’t it be better if there were many more, independent opportunities for employment?

Please consider sharing your thoughts in the comments.

Editorial, Programming

Path Of The Python, Ruby, And Perl

Leave a comment

Many programming languages were designed to promote a certain style or way of working. Python, for example, strives to provide a single ‘obvious’ path to a solution for any common problem. At the other extreme Perl seeks to provide many different ways to do something. Ruby takes a curious middle ground by providing multiple solutions yet promoting only one or two conventions.

Community is also a big factor in the way computer languages are used, developed, and taught. Within the Ruby community the Ruby on Rails has raised awareness of the convention-over-configuration paradigm.

Having a variety of shortcuts such as those in Perl and PHP have proven useful when I’m in search of a quick and dirty solution. That is likely why Perl has been so popular for getting simple jobs done.

Maintaining software as it grows and changes is one concern I have with very feature rich tools like Perl and PHP. After more than 10 years working with PHP I find I still need to check the manual to confirm behavior every single time. Javascript seems to have a similar problem, though more so because of the many different implementations.

While language usage doesn’t always strictly follow the intended usage, there are examples indicating that design philosophy impacts outcomes:

Ultimately it is up to the software engineer to decide which road to take to get to the solution. Familiarity with the platform or style is another significant factor I’ve seen at work in the mind of individual engineers.

How about you? Do you have thoughts or experiences to share? If so please leave a comment.