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.