KDE 4.2.4 Released to Fink Unstable

Just a note to say that I’ve released KDE 4.2.4 to Fink unstable. And now it’s time for the fun part: big bold red text telling you it breaks stuff.

KDE4/X11 Plasma Desktop on Mac OS X
KDE4/X11 Plasma Desktop on Mac OS X in Xephyr
 
Working KOffice file asociations
Working KOffice file asociations

Actually, that was just the text saying that I was going to have big bold red text telling you it breaks stuff. Here’s the real thing:

It breaks stuff!

But let me explain: it makes things better! Because of some esoteric stuff relating to case-sensitivity, existing packages, and bugs in Fink dpkg, there were issues on a number of people’s systems with the existing KDE packages and conflicting paths. Of course, the root of the issue is that Fink didn’t have a proper “/opt” type directory, so a number of packages for quite some time have been using “/sw/lib” for that purpose (/sw/lib/qt4-x11, /sw/lib/flex, etc.)

Since I was going to have to move things around anyways to fix this issue, I decided to do it right. As of Fink 0.29.7, the package validator accepts “/sw/opt” as a valid path to root packages. All of the KDE4 packages have been changed to use this new path, so when you upgrade to KDE 4.2.4, you will end up with a nice fresh clean KDE in /sw/opt/kde4/x11 or /sw/opt/kde4/mac (or both).

But wait, there’s more!

I’ve also spent a lot of time fixing bugs and tweaking some fink-specific behaviors so that KDE integrates better with your Fink experience.

  • Fink’s kdelibs4 automatically knows about the usual locations for kde4 files, so all KDE4 apps will start properly without needing /sw/opt/kde4/{x11,mac} in the path. This includes KDE4 apps launched from the Finder.
  • The kdebase-workspace package is now supported for KDE4/X11. That means you can start a full KDE desktop!
  • As a test, I created proper Info.plist files for KOffice, so file associations actually work. Till Adam has been working on a more robust way of doing this in the future, but if I find the time I might work on setting up more associations for common KDE apps in the mean time. (Kommon apps?)

So, for those of you who have already tinkered with KDE4 in Fink, I’m sorry to say it all needs an upgrade. But, on the bright side, once you do, you’ll have a much nicer KDE.

As always, if you run into any issues, please let me know.

Share on Facebook

The Open Source Philosophy (Continued)

The conversation has continued over at the 451 CAOS Theory blog. In response to my musings on intent, David Dennis asked a great question:

Benjamin,

A question for you (and Tarus). Is this topic important to you because:

  1. You believe it’s an important marketing differentiator for the software you work on vs. competitors
  2. You believe it’s an important philosophical / moral issue worth evangelizing
  3. both

Tackling a) involves traditional marketing objectives around branding, awareness, messaging, positioning, etc. Not necessarily a cake walk, but certainly possible to make progress.

Tackling b) involves changing the way people think and behave, which is much much more challenging.

My response is:

Definitely both.

From a personal point of view, I’ve been involved in open source software since before the phrase was coined, so I do feel that it is at least a personal philosophical issue. BUT I’m also a pragmatist, and I know that arguing purely for philosophy’s sake will not convince anyone.

That said, that philosophy drives me to support the companies that I think are doing it “right.” I work for OpenNMS not just because I think the software’s great, but also because I love that we can compete with “the big guys” by having a better community.

Part of the reason that we get so passionate about it is that a lot of these “does it really matter?” conversations start with the implication that we’re already failing to compete, which is just plain wrong. I’m sure that’s why we probably often sound defensive when we are hoping to sound convincing. 😉

I’m the first to roll my eyes at the “true believers” — while I think that in the end open source is a better way to do things in a “pay it forward” kind of way, I believe it’s better from a philosophical and pragmatic way. It won’t work for everyone, but it can work for open source projects as an alternative to big-money funding.

I am a child of the VC tech industry. I’ve worked at startups and I know what it feels like to work on software you think is great only to be shut down and have the IP sold off, just because the VP of sales didn’t do his job. It’s refreshing to work for a company that starts with community first, and grows by being truly profitable, rather than by incurring massive amounts of debt. (See: current economy.) It’s refreshing to not be one of 10 companies the VC bets on, and if 9 of them fail, “eh, oh well, that’s statistics.”

Since we grow as we have profit, rather than funding, the biggest investment we can make is in our time, improving the software, and growing the community. There is nothing wrong with the “fauxpen source” companies’ business model, they are welcome to write good software as best they can, and get market share, but in the end, we do differentiate by our openness and our interaction with the community. When they co-opt the phrase that was meant to be equivalent to “free software” to now mean “kind of free software,” it does pure open source companies a disservice and it is a lie by omission that they equate their software to be “just as free” as ours.

Sure, that’s competition, but that’s why it’s important for us to get the word out that there is a difference.

Share on Facebook

The Open Source Philosophy

There has been a lot of discussion recently on the Open Source Definition, and the use (and abuse) of the term “Open Source.” One of the things that has been missing from this discussion is a higher-level overview of where the friction between “open source” and so-called “fauxpen source” comes from: intent.

The Open Source Definition arose out of the ambiguity of the word “free” in “Free Software,” as defined by the Free Software Foundation.” In the English language, “free” is a loaded term that has two meanings: “freedom”, and “costing nothing.” It was created to get rid of some of the emotional baggage that came with the intense philosophical point of view of the FSF, but just because the OSD is more “business-friendly” does not mean that it doesn’t have the philosophy and intent of openness behind it.

This friction comes from two very different approaches to open source that I think have been missing from a lot of the discussion regarding how open source applies to business models. I’m going to call these “community value” and “monetary value.”

In some ways, this dichotomy reminds me of the GPL (GNU Public License) versus the LGPL (Lesser GNU Public License). The GPL is a pure open-source license, which guarantees the user’s freedom by making it so that no software that uses GPL software can hide or restrict that use in a derivative work. The LGPL, on the other hand, was a compromise, a pragmatic license which allows one to create free software, but it does not require free distribution of things that link to that software. The LGPL has always clearly been discouraged by the FSF precisely because it compromises the freedoms guaranteed by the GPL.

Open Core: Nurturing Monetary Value (“Lesser” Open Source)

Advocates of using the term “open source” to apply to open-core and similar business models approach open source from a monetary value point of view. It is an approach of pragmatism: you create a business plan, get venture capital to get going, and sell software licenses to (hopefully) eventually pay back the VC firms and continue to grow. In many ways, an open-core business is exactly the same as any other startup. Open Source is not a fundamental philosophical part of the business, it is instead used to cut costs, and to help grow “buzz” about what your company is doing, and perhaps even get some free QA, bug reports, etc. The focus is not on creating a community to draw customers indirectly by improving the product, but to draw customers directly by creating awareness. To meet the demands of the venture capital, it requires a fast-growth, high-yield business model, and the community model doesn’t grow that fast.

In the end, how much work you do nurturing a community is directly a matter of how many you can convert to paying year-over-year for software licenses, or whatever other artificial scarcity you create. Once customers have decided they want the features only available in the up-sell (“enterprise”) version of your software, they have more resistance to changing to another product.

This is growing monetary value. The open-source community in a “monetary value” business is a side-effect of a marketing push to draw licensed customers. If the community goes away, you still have an essentially standalone commercial business that can continue just as if the community never existed. This is not to say the community doesn’t provide value, nor that it doesn’t derive value from the open source portion of their software, only that the business plan itself doesn’t hinge on the openness of the software.

Open Source: Nurturing Community Value (“Pure” Open Source)

On the other hand, “pure” open source business models (services & support, like my employer) approach business from a community value point of view. This is not to say that pure open source companies don’t want to make money — only that to be successful, we compete with much bigger companies by multiplying our value with that of the community. To be able to be competitive with companies with huge amounts of seed money, we can’t afford to treat our community just as a resource to be mined; our community is what makes it possible to support a large user-base with a small number of employees. Our community are like-minded individuals, working on this project with us together.

Since we are not beholden to venture capital, we don’t have to get quick returns to maximize stockholder returns. Instead what we need is to work with the community to make great software, and to continue to challenge ourselves to extend and expand our knowledge of that software, so we are able to provide our expert opinions as a service worth paying for. As long as we can pay the bills, give ourselves a comfortable salary, keep customers and the user-base happy, and grow the business, we consider ourselves successful. Our goal is to become the de facto network management platform, and we can do that better by not being in debt to venture firms for years.

On the surface, the value we and our community get from each other may not look that different from that of an open-core company, but looking deeper, there are a number of advantages to the “slow and steady wins the race” methodology we use:

Everyone Gets the “Enterprise” Version

You are not held ransom for features that are only in the for-pay version. You can evaluate the product as it truly is, without time-limited evaluation licenses, crippleware with features missing, or annoying shareware reminders.

No Software Licenses

The software isn’t artificially limited, it is capable of whatever your hardware is capable of without an arbitrary restriction because the sales VP decided that’s where to draw the line. Note that it’s easy to think that Red Hat is a counter-example, since they charge licenses for installed hosts, but from a freedom perspective, you can install the code on as many hosts as you like (ie, CentOS) without restriction, the restriction is only on “official” support.

Everyone Benefits from Community Involvement

When the community adds value, everyone benefits. Users help each other with issues, provide patches, documentation, and so on. The community contribution to OpenNMS has been huge — not only major features, but default configuration for large amounts of network gear, which OpenNMS now supports out of the box on every new install.

Everyone Benefits from Commercial Involvement

Since the code is 100% open-source, customers who pay for custom development not only get their own value from the transaction, but the software goes back into the mainline, and benefits everyone.

An anecdote: We had a support customer who paid for some custom development for a somewhat esoteric feature. It was originally done in a branch of OpenNMS something like 5 or 6 years ago. The OpenNMS code base has gone through huge upheavals, refactorings, and architectural changes since that feature was created, but since it was released back into the OpenNMS mainline, when they finally upgraded their production system to an up-to-date OpenNMS release, the feature continued to work. If a consulting company did that same custom work as an HP OpenView plugin, they would have to port/implement it all over again after 3 major version revisions of the upstream software.

100% Forkable

While we make a living supporting OpenNMS, we do not “own” the project. (Although, we do own the OpenNMS trademark — the realities of business in the US require it if we want to be able to protect the name of the project.)

At best we are stewards, but the list of OpenNMS employees is a fraction of the number of “core” contributors, and the core contributors are a fraction of the number of users who have added value to OpenNMS over the years.

We run and guide the project, but only because the community trusts us to do so. Our job is to earn that trust, by upholding the principles I’ve outlined above. When we do so, everyone gets value from OpenNMS. If we fail to do so, the OGP will “vote us off the island,” and if it becomes bad enough, the source is fully available so it can be forked to something the community approves of.

Either Approach is “Better,” but Only One is Truly Open

In the end, it’s like the difference between a stable community bank who personally knows every person it gives a loan to, and an investment bank bringing in money fast with high-risk derivatives; they are focused on providing value to two entirely different sets of people. Either approach is better depending on your point of view — they each have their advantages. However, in the end, I believe it is disingenuous to claim that open-core and similar business models have as much right to the phrase “open source” as pure open source businesses.

Share on Facebook

Shorn in the U.S.A.

Shorn in the U.S.A.

Alright, folks, the bearding has commenced.

Now’s your chance to make a pledge for the Carolina Hurricanes Kids ‘n’ Community Foundation. Just hit the “Pledge a Friend” button, and put in “Benjamin Reed“.

If you know me, you know my dedication to never exposing my unfortunate double-chin to the horrors of sunlight. Don’t let this sacrifice be in vain! Pledge now!

Share on Facebook

It’s Playoff Beard Time

many-faces-of-ranger-rick-animation.gif

In the ’05-’06 Stanley Cup run, I grew a pretty substantial playoff beard, just for the heck of it. (see fig. 1, pictured right)

This time, the Hurricanes are doing a great charity event for the Kids ‘N Community Foundation: the Beard-A-Thon!

When the regular season games are over, I’m going to shave, and then grow a playoff beard as hard as I can.

Now, as I mentioned, it’s a charity event, and I need you folks to help me out, by pledging at the Beard-A-Thon page. Don’t forget to enter “Benjamin Reed” where it says, “ There’s a specific beard grower I’d like to support.”

Pledge now!

Share on Facebook

KDE 4.2.2 in Fink Unstable

I’ve just committed all of KDE 4.2.2 to Fink Unstable.

There’s still a lot of rough edges, but it’s definitely at least beta quality, and a lot of apps work great. It includes a number of fixes, including updated scripts to register all of the desktop files properly with ksycocoa on post-install, case-sensitive filesystem fixes, and a number of other packaging fixes. I’ve also finished packaging all of the “core” KDE distribution.

I’ve got Amarok working in my experimental tree, I just need to do a little more testing before I can release it (It’s based on a snapshot of what will become Amarok 2.1.0, since 2.0.x has some build issues on Mac OS X that are difficult to resolve). Also, the KOffice folks just put out a release candidate that I’m working on finishing up packaging on. Hopefully I will have that out soon.

As always, please let me know if you run into issues. I’ve test-built on 10.5/i386 and 10.4/ppc so I’m sure some 10.4/i386 and 10.5/ppc users will give bug reports soon. 😉

Share on Facebook

Best Useless Stats Ever

If you’ve followed this blog for a bit, you know that I write music and (finally) released an album last year.

One of the places my music is available for download is bandcamp.com, who offers up a nice little download/portal service where you can make your music available. You can get my music there for free at 128kbit, or if you want to support my music, or get a higher-quality format (all the way up to FLAC and Apple Lossless!), you can name your own price.

I was looking at my download/listen statistics, and I saw something strange. They do 60-day, 30-day, week, or daily graphs, along with defender graphs.

Defender?!

So I clicked on it, and I saw the coolest most useless statistics graph ever. You can play defender in your graphs. The little UFO flies around, there’s people on the ground, and you can move your ship back and forth and shoot them. Awesome!

60-day graph:
60-day graph

Defender graph:
Defender graph

How cool is that!!?

Share on Facebook

KDE4 Fink Unstable Releases

I’ve had a chance to get a few more of the KDE4 packages polished up into what I hope is a releasable state. 🙂

Please give them a shot, let me know if you have any issues, if things don’t work as expected. I know one major thing to look into still is to get document-opening working. Right now the KDE desktop files describe which apps should open different document types, but that is not being translated to OSX’s document-opening APIs.

The following packages were released to unstable today:

  • digikam-mac and digikam-x11
  • kdeaccessibility4-mac and kdeaccessibility4-x11
  • kdeadmin4-mac and kdeadmin4-x11
  • kdeartwork4-mac and kdeartwork4-x11
  • kdeedu4-mac and kdeedu4-x11
  • kdegraphics4-mac and kdegraphics4-x11
  • kdemultimedia4-mac and kdemultimedia4-x11

Big ones left on the hitlist are amarok2 and koffice2. Amarok2 I’m starting work on again as a snapshot of the 2.1.0 build, since there are some issues with 2.0.x building on OSX. KOffice is actually working pretty well in my experimental tree, but 2.0 release candidate is due out in the next week or so, so I’m going to wait to update to that before doing a release.

Share on Facebook

This Week in OpenNMS: Moving to a New Home

Since this blog is more about my own personal development on OSX, Fink, KDE, and OpenNMS, and This Week in OpenNMS is about, well, all of OpenNMS development, I figured it was high time to move it to somewhere more official.

Without further ado, I present to you: This Week in OpenNMS. Same bat-time, different bat-channel.

RSS is still available, but the url has moved here, rather than getting everything through my blog.

Please, update your links!

Share on Facebook

KDE 4.2.1 in Fink

Yes, that’s right, a post to my blog that isn’t about OpenNMS. 😉

As you can tell, I’ve been pretty busy having fun hacking on OpenNMS lately. While I have been keeping up with my Fink work to some extent, one major thing was still looming: finally getting all the work I did on KDE/Mac released in Fink, now that things have stabilized.

If you’ve been watching the commits for the last few months, you’ve seen the beginnings of that work. Updates to Qt, releases of support things like strigi and soprano… The big hurdle was getting D-Bus in a state where it plays well with KDE/Mac. After some initial hiccoughs, the D-Bus updates have been released to Fink now, and seem to be working well for people.

Today, I released the base packages for KDE 4.2.x into fink: kdelibs4, kdepimlibs4, and kdebase4.

Because of the cross-platform nature of KDE, I’ve released them in 2 variants: mac and x11, so you can run konqueror as an X11 app, or as a mac app. 🙂

Some things will only be present in one or the other, for various reasons (X11-specific features, etc.) One thing that will be in the X11 variant that is not there now is kdebase-workspace, so no plasma desktop as of yet. I’ve built it, but it doesn’t act right currently, so I’m waiting to release until it’s in a usable state.

This is still early test stuff, so if you run into issues with it, please feel free to let me know and I’ll see what I can do.

I can’t thank enough Orville Bennett and the other KDE/Mac folks. They have picked up the early work I did on porting and ran with it, helping polish it into a nice, buildable, and solid set of code while I was on my “hiatus” from KDE packaging. 🙂 They have done a lot of great work in helping bring native mac KDE from “freakish mutant” to “used every day by KDE developers.”

In the coming weeks I hope to get more of the base KDE packages done. I’m in the testing phase for koffice, amarok, kdeartwork, and a couple of others, and working my way through packaging more. I’ll post as I get anything interesting.

Share on Facebook