Who can NOT afford Open Source Software?

I just read an interesting article (http://stop.zona-m.net/2012/01/who-can-afford-open-source/), where a maker of school administration software (I’m thinking like Blackboard?) in Italy thinks:

you must either have a big organization that supports the development of that software, or be yourself a big company that can afford to make money also in other ways.

It really makes me sad that this business owner has reached this particular conclusion. I’m not familiar with this product, of course, and I don’t speak Italian, but I imagine that the owner is selling licenses and guaranteeing support, etc. as a sole proprietor or with a couple of employees. He has his code in a vault, and is spending time on development and (likely the biggest time sink) support.

Imagine now, if you will:

This same person concentrated his efforts in developing an open source community around his product. If it’s a good product and he is committed to open source, people will join the effort. Suddenly he has 2 contributors, and then five. and then 10. and then 50, and he’s steering his project instead of having to produce everything himself. His project is more robust because more eyes have seen the code. It’s stronger because the group is large enough to effectively integrate test-driven development and CI principles.

So how does our project owner make money? Well, there are several open source business models (by no means an exhaustive or scientific list):

  • The Subscription Model (a la Red Hat) – You sell access to the software for a given time period, and can attach support SLA’s on as premiums. Proven to be effective.
  • The Support/Training Model – The software is open source, and the company sells installation and implementation expertise. They typically also offer training and customization. Proven to be effective by OpenNMS,Zabbix, and many others.
  • The Open Core Model – The core application is open source, and the company offers extensions or plugins that may be closed to customers, along with support & training. I have some personal issues with this model, but several companys (Zenoss, Vyatta, and others) are currently making money with it.

So at the end of the day this project could have:

  • a better code base
  • a more robust development environment
  • wider adoption
  • more contributors

and many other benefits by moving to a FOSS business model. Of course I’m not saying that this person should automatically do this. I’m not a business advisor by any stretch of the imagination. But I really don’t think that his statement holds water. It is completely and increasingly feasible to make money with an open source software projcet.

Is a Government-funded Open Source project an oxymoron?

Recently I’ve been talking with a co-worker who is working to re-fashion the community standards for a pretty large open source project that is funded almost wholly by the federal government. The project is several years old at this point. While it has a solid user base, it has not been successful in fostering a community of contributors. Up until now the government has contracted out a development team to develop and refine the product.

It was decided (I don’t know at what level) that this project needed to be “more open-sourcey”. The tasks that were came out of this desire were to re-evaluate and modify the internal open source process as well as the public open source strategy. At this point I was totally un-involved with the project and these tasks went into the team’s hopper to be made into sausage.

At the 11th hour, I stumbled on to this issue and the project leader forwarded me the documents that the group had worked out. Now, my personal philosophy (heavily borrowed from others) to build and have a healthy FOSS project is the following:

  1. Release the project under a known and accepted Open Source license, and do it properly.
  2. Keep barriers to community contribution as low as practically possible.
  3. Keep processes within the project as transparent as is practically possible.

Of course each project has it’s own specific issues and needs, but I sincerely think that if a team is solid on those three things, most other things will sort themselves out by a community being a community.

The process that this team had come up with wasn’t particularly close. It involved emails, approvals, in-house SVN branches (yes, they still use SVN), and other methods that are certainly not “low barriers” to a typical contributor. After some discussions with the team members and asking some questions, the process ended up significantly lighter, utilizing the already existing code-review system that has a 4-5 field registration form.

While this ultimately was a success, the part that really amazed me was how this project almost fell into the trap of being “sorta’ open source”.  I later found out that a member of the project had already spoken with multiple experts in the arena of building open source communities and somehow their advice had been disregarded.

Within the project there was a desire for the “paid team” to control the core code base, with no real mechanisms for a community to become involved with it. The “community” contributions would essentially be relegated to plug-in type extensions. One thing that has never proven successful in the FOSS world is keeping the community at arms length and still expecting them to be contributors instead of simply consumers.

Open Source is loud and noisy when at its best. In a perfect project, decisions are a practice in theoretical democracy. In my experience, government-funded projects that claim to be FOSS don’t want to try and manage this type of environment. I can’t really blame them, as it’s hard to attribute billable time to a 17-year old in Denmark who fixed a bug simply because it was interesting. There’s a lot more to being an Open Source project than allowing downloads from a version control repository for no fee, and the government projects and contractors I’ve worked with to this point are having a hard time learning that lesson.

Is Unity tearing Ubuntu apart?

In my mind, Ubuntu is a mass of contradiction, and I’ve never quite been able to wrap my head around it.

Ubuntu, at its base concept, I get. They’re “Debian-based”, according to their documentation

Ubuntu builds on the foundations of Debian’s architecture and infrastructure, but has a different community and release process.

So they have no real relationship with the Debian team. They’re not upstream or downstream. They just like apt-get and the funky way Debian configures apache? It just has never made sense to me. Ubuntu is apparently a pretty good desktop OS (I haven’t used it since 8.10), but its LTS concept is a poor excuse for an enterprise operating system.  And then there’s Canonical and the apparent attempt to make Ubuntu a product? or monetize it? IDK. They’re doing something but it isn’t clear to me.

If they really thought Unity was the way to go, why not convince the rest of the GUI developers around the world? I can’t imagine that if the powers that make Gnome and KDE and LXFCE and all of the other great window managers out there really thought Unity was where it was going to be, they wouldn’t either incorporate the concepts (making them all stronger) or rally behind a single standard.  Instead they are going at it alone and alienating their community in the process.

My thoughts aren’t all together on this.

http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/A-Disturbing-Dialog-About-Ubuntu-and-Unity

This article got me thinking about it. Just not a cool way to run an “open source” project, IMHO.

(A few) random observations from day one of Ohio Linux Fest

I came up yesterday from Richmond, VA with two other Linux geeks and we’re all experiencing our first Ohio Linux Fest. A few observations from day One.

  • The Columbus Convention Center is HUGE. Getting from the hotel to the actual meeting rooms is sort of a spoof of The Two Towers in its own right. Definitely a journey.
  • The size of the convention center, so far, is making it feel a little less cozy as compared to SELF this past year. I’ve no doubt that will change tomorrow.
  • The people here are top-notch, period.
  • The t-shirts are pretty cool, even if they are “Ohio State Red”.
  • A lack of free wifi in the convention center and a shortage of power plugin spots isn’t great.
  • The Red Roof across the street doesn’t have a great continental breakfast
  • Both local bars we’ve tried so far have been great
  • I’m really looking forward to tomorrow.
I’ll try to have something more substantive up later tonight, booze-willing. 🙂

Essential Tools When starting a new project #4 – issue tracking / project management software

A few weeks I decided to help what I think is a very good idea (more on that, I’m sure, in the future) try and get itself off the ground. In my mental preparations for this task, I began to wonder what we were going to need at the very beginning stages that would allow our work to proceed. I came up with this list:

  • Collaborative Software
  • Version Control System
  • Document Repository (with versioning abilities)
  • Issue Tracking Software

Since then I’ve talked about 3 of the 4 tools I think any “IT person” should have ready and available when a new project starts up; I’ve taken a look at Collaboration Software, Version Control, and a relatively new concept in my tool list in a true document repository. Last on this list is issue tracking and project management software. Of all of the tools I’ve been talking about, this is where things can get crazy really fast.

Why do you need this application in your corner when you first start out? I’ve seen too many projects flounder at the beginning and never recover because they couldn’t figure out how to go about eating their particular elephant. These tools, whether you want to use Gannt Charts or Burndown Charts, are designed to help you organize your work and attack it in a way that is consistent and doable. You know, project management. 🙂

A Google search reveals at least 8 quadrillion project management and issue tracking apps out there (an estimate of course). For the purposes of this talk I’m going to stick with the tools that I’ve personally worked with that I think can do the job for which they are designed. I’ll be excluding closed source garbage apps I’ve been forced to use in a few engagements that are parts of large “solution suites” that companies feel compelled to make and purchase without good sense. Out of the small universe of applications out there, my personal top few are:

  • Jira – Like Confluence, Jira is another Atlassian product that is trying very hard to become the standard for issue-tracking / project management applications. It’s a java application (amazingly stable, though), with a huge community that contributes plugins that do all sorts of amazing stuff. It’s biggest downside is that it’s not open source, but they try to overcome at least some of that stigma by offering Jira for free to open source and some other types of projects. They also have a 10-user/$10 license where the $10 goes to charity that is GREAT when starting up a new project.
  • Trac – I’ve mentioned Trac before, because it has some aspects of collaboration software built-in with its wiki (it can serve double-duty for smaller/more straight-forward projects, even). But at its heart it’s an issue tracker. There are now plugins that give you a more Agile look and feel in Trac (my personal fave), as well as the traditional milestones / versions, etc.
  • Bugzilla / Mantis – I’m putting these two together not because they are the same thing but because they fill the same role in a project. They are bug trackers, plain and simple. While some people use them to do it, they isn’t really a project management component to these applications. Mantis is written in PHP and Bugzilla is written in Perl. Both are open source. Bugzilla certainly has the edge in users, with a HUGE community that includes Mozilla, RedHat, the Linux Kernel and others.

Like I said at the beginning, there are more applications that purport to be issue trackers / project management applications than I could talk about in a lifetime. But in my lifetime, I’ve used several, with the short list above being the ones that worked best. Of them, I’m a big fan of Jira because of its interface and great Agile plugin (greenhopper).

NASA’s biggest contribution?

While NASA’s space program was essential in starting the space race and proving that humanity can exist off the Earth, it’s demise may do as much to get us into space as it’s past success.  I think that this failure, fueled by the political environment in the US and magnified by its own archaic management structure that has been in place since Apollo, is going to do more to make space accessible to mankind than anything that they ever launched or lost on the drawing board.

Now follow me here. I love NASA. I think the concept that they started with, to get a team of bright and dedicated people together and solve the biggest problems of the day is amazing and I strive to realize a similar situation in everything I attempt. They have brought us amazing things that have altered our world more than we can comprehend. I imagine that any true survey of technology in mine or my parent’s lifetime is going to spend a large portion of its time in some back room of a NASA lab.

Unfortunately, NASA wasn’t able to keep up with technology as it evolved with ever-increasing speed. Possibly as bad or worse, NASA lost our imagination and didn’t know how to re-catpure it. Even the most successful NASA project, the Hubble telescope, is marred by its painful birth with mal-focused optics brought on by simple math errors.

But this sad time for NASA is, I believe, going to have an ultimately beneficial effect on mankind’s effort to grow out of low Earth orbit. Without these failures, and more importantly this lack of interest in public funding for space exploration, the private sector may have never grown like it has in the past decade. These Henry Ford types like Richard Branson and Bigelow Aerospace, are key to forming the initial competition that is going to make travel into space cheap and safe.

Even more importantly, if NASA had maintained our wonder like it did in the 1960’s, organizations like Mach30 wouldn’t have formed to fill the void left by NASA in the 1990’s and 2000’s. Groups that realize the obvious truth that the next great frontier is in and beyond orbit are the platforms that are ultimately going to bring mankind into space as a part of life. This is truly the beginning of the most exciting period of human development.

The Practical SysAdmin – Email

As I mentioned here, I often find myself looking at the chosen solutions that I choose and wondering if they are truly in line with the Free and Open Source ideals that I advocate. There are times when the truly 100% FOSS solution just isn’t time-effective for the situation. To that end, at least in my own mind, I’m endeavoring to establish a new philosophy within the universe of System Administrators.

Practical Systems Administration (noun) – The philosophy of adopting open source applications and principles whenever possible, but allowing for the occasional closed-source if it is truly an innovative, cost, and time effective product.

So what does this mean? Most of the time, not much at all. In my experience, the vast majority of the time an open-source, community-driven product is going to be a much better long-term solution within your IT Group than closed-source or pay software. There is a great webcast and talk about it at opensource.com here, with the CEO of Automattic (who make WordPress) and others.

But there are exceptions that can greatly affect your IT infrastructure. If taken advantage of, not only can you save time by not taking care of things that you don’t want or have to, but your company saves as well. The biggest example of being a Practical SysAdmin so far is with Email. You know it. Email, that bastion of corporate IT.

We’re not going to talk about Microsoft Exchange. Implementing that, and paying the small army to cajole it into relatively constant operation, is as closely akin to burning $50 bills as I can think.

There’s also Zimbra. Owned by VMWare, Zimbra has adopted an open-core business model. I’ve mentioned my dislike for this before, and it eliminates Zimbra as my email solution.

The truly open source solution for email is:

  • Get a box (or cluster) up and running as your ClamAV scanner
  • Get another box (or cluster) up and running as your SpamAssassian scanner
  • Set up a your outbound mail server (or cluster) – I like Postfix
  • Set up your inbound MTA (or cluster) for POP and IMAP access – I like Dovecot.
  • Don’t forget to set up your mail stores on some sort of shared storage
  • Set up something for webmail access – is roundcube still around?
  • String all of this together, including DNS that won’t land you on blacklists all the time. Don’t forget the SPF records.
For a company the size of mine (50 email-crazed employees), this would represent at least 6 physical servers, and hours every week to maintain and fix issues. It’s not a bad paycheck, I’ll happily admit. But I proved a long time ago that I could set up email for a company. There is no innovation in it, and there is no innovation in email for my company. At its absolute best-case, it’s a losing proposition.
There are some edge-cases, of course. If our company was big into email blitzes, a portion of what I outlined above might be a good idea. But we’re not. We use email like we use the telephone. We use it a lot, and we want it to “just work”.
Which leads us to the wonderful world of Google Enterprise Apps. For $50 per user/year, you get corporate access to Google’s Gmail platform, plus Google Docs, Reader, and about 80 other Google services. All tailored for your domain. So for our 50 users that’s $2500 annually for email. In the past year, the 2 people in the IT Group at my company has spent ~3 hours troubleshooting email issues. So out of ~4,000 hours of IT work, 3 or so were spent on email issues. And Google had a 99.84% uptime last year for the service. 2 people couldn’t provide that uptime percentage when running it all in-house (unless they were REALLY obsessed about email. Like, scary obsessed). It’s just not feasible.
The storage space is also worth considering. Each user gets 25GB of storage. To hold that in house, our mail store would have to be 1.25 TB (usable) for our current employee list. That’s also not counting spam queues or anything else.
Spam? How is YOUR gmail spam filter doing? Security? When was gmail actually hacked? I’m not talking about gmail USERS, but actually GMail. I don’t know of an example (If it exists, let me know).
There are likely some examples (I’m thinking of FISMA compliance nastiness with the government) that may make GMail not an option. But for 5AM Solutions, it’s an incredible return on a $2500 investment this year.
As for open source, no. Google Apps is NOT open source. Google IS one of the biggest contributors to the open source community in the world, but this project is not among them. There are attempts to re-create the usefulness of GApps as a purely open source platform (see OpenGoo – stil active?). But it’s not there yet, and with Googles pockets and desire to stay creative and innovative, it likely never will be there.