The sudden death and eternal life of Solaris

Bryan Cantrill wrote this blog post on the death of Solaris.  Here’s a bit like the most about it, which talks about the proprietary software vs. Open Source:

Assuming that this is indeed the end of Solaris (and it certainly looks that way), it offers a time for reflection. Certainly, the demise of Solaris is at one level not surprising, but on the other hand, its very suddenness highlights the degree to which proprietary software can suffer by the vicissitudes of corporate capriciousness. Vulnerable to executive whims, shareholder demands, and a fickle public, organizations can simply change direction by fiat. And because — in the words of the late, great Roger Faulkner — “it is easier to destroy than to create,” these changes in direction can have lasting effect when they mean stopping (or even suspending!) work on a project. Indeed, any engineer in any domain with sufficient longevity will have one (or many!) stories of exciting projects being cancelled by foolhardy and myopic management. For software, though, these cancellations can be particularly gutting because (in the proprietary world, anyway) so many of the details of software are carefully hidden from the users of the product — and much of the innovation of a cancelled software project will likely die with the project, living only in the oral tradition of the engineers who knew it. Worse, in the long run — to paraphrase Keynes — proprietary software projects are all dead. However ubiquitous at their height, this lonely fate awaits all proprietary software.

There is, of course, another way — and befitting its idiosyncratic life and death, Solaris shows us this path too: software can be open source. In stark contrast to proprietary software, open source does not — cannot, even — die. Yes, it can be disused or rusty or fusty, but as long as anyone is interested in it at all, it lives and breathes. Even should the interest wane to nothing, open source software survives still: its life as machine may be suspended, but it becomes as literature, waiting to be discovered by a future generation. That is, while proprietary software can die in an instant, open source software perpetually endures by its nature — and thrives by the strength of its communities. Just as the existence of proprietary software can be surprisingly brittle, open source communities can be crazily robust: they can survive neglect, derision, dissent — even sabotage.

On React and WordPress

I have a great deal of respect for Automattic in general and Matt Mullenweg in particular.  They have done an amazing job with WordPress, which is now used by more than a quarter of all websites.  But they are also a great example of how companies can work in the Open Source software space.

It’s not all just business.  Automattic raises the ethics bar quite high.  And today there is an excellent example of how they do it.  Check out this blog post by Matt on why WordPress will be moving away from the React JavaScript framework developed by Facebook:

I think Facebook’s clause is actually clearer than many other approaches companies could take, and Facebook has been one of the better open source contributors out there. But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.

Respect!

The Minimally-nice Open Source Software Maintainer

Brian Anderson shares a few thoughts on how to appear as a minimally-nice Open Source Software maintainer.  Maintaining Open Source Software projects is a demanding job.  And the more popular the project is, the more demanding it is.  Brian shares the following practices that minimize the effort while you still maintaining a positive atmosphere for the project’s contributors:

In summary, do these things if you want to appear to be nice, and also if you want to actually be an effective open source software maintainer:

By consistently exhibiting a few simple behaviors, one can at least look like a kind and decent person. Maybe someday we all actually will be.

Huginn integration platform

Huginn is an integration platform that manages triggered events with agent services according to workflows.  Unlike many hosted services (Zapier, IFTTT, bip.io), Huginn is an Open Source application written in Ruby on Rails, and can be hosted, extended, and customized locally.

If you can read Russian, make sure to check out this post that shows some example use case scenarios.

Boostnote – Open Source note-taking app for programmers

Boostnote is yet another alternative for taking notes.   This one is an Open Source and is built for developers.  Some of the features – Markdown support, search, cross-platform, works offline.

There is also Boostnote Team edition for, you know, teams.