open source

“Kotlin Quick Reference” book

Somewhere around a year ago I started working on a Kotlin programming book, but then I had to get away from it to work on other things. When I got back to it recently I looked around and felt like the world didn’t need another “Introduction to Kotlin” book — there are a couple of good ones out there, including Kotlin in Action, and the kotlinlang.org documentation is excellent — so I decided to ditch the project completely.

The Red Hat ethos

The URL contains a statement of the Red Hat ethos. A couple of good quotes:

Open source is a development model, not a business model. Red Hat is in the enterprise software business and is a leading provider to the Global 500. Enterprise customers need products, not projects and it’s incumbent on vendors to know the difference. Open source projects are hotbeds of innovation and thrive on constant change. These projects are where sometimes constant change happens, where the development is done.

Notes on Apple’s Swift open source development

These are a few notes on Apple’s Swift open source development project, taken from this mailing list post by Apple’s Chris Lattner:

- Open source is pretty great. It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.

- Open source also brings challenges.  I think it is fair to say that “open design” is slower and less predictable than “closed design”. However, the end result is significantly better, and therefore the tradeoff is worth it.

- Software scheduling (particularly with open source) continues to be difficult-to-impossible to predict.

- It is *good* to have high goals, but we need to do a better job of communicating that “goals” are not “promises” so that people don’t feel misled.

“How I unexpectedly built a monster of an open source project” (OMZ)

medium.com has a good story on how Robby Russell built the “oh my zsh” project, and how that project evolved. “Lessons Learned” from the project:

1) Don’t start with a wildly ambitious goal.
2) Don’t try to account for every scenario.
3) Don’t try to make it perfect.
4) Don’t try to be everything to everyone.
5) Don’t stop thanking contributors.
6) Don’t forget the documentation.
7) Don’t forget about the rest of your life.
8) Don’t forget to have some fun.

Politics, technology, leadership, and open source software alvin February 8, 2016 - 5:48pm

This blog post titled nanomsg postmortem and other stories is so good I wanted to share this part of it on “politics and technology.” The whole thing is a great read, as is this other article titled Requiem for Nanomsg. Both articles tell a fascinating story about software development, “politics,” and leadership.