for developers the best learning materials are third party tutorials

It has always surprised me in the past that the best learning materials for any language or development technology are written by those who didn’t build the technology. The best book for learning C++ way back in the early days was not either of inventor Bjarne Stroustrup’s early books. It was Lippman’s excellent C++ primer. For years the best books on learning either Rails or Ruby were written by Dave Thomas (Agile Web Development in Rails and Programming Ruby) who didn’t have much to with developing either of the two technologies (although he did write the first version of RDoc). And in our opinion, his book was surpassed by later authors such as Fulton’s excellent The Ruby Way.

The same is true for Rhodes. We were pretty happy with our tutorial. And we work pretty diligently to keep it current and accurate at all times. We’ve gotten a lot of kudos from developer users that its pretty good. But, lo and behold, we’ve been one-upped by one of our users, Makoto (who is working on a Mobile Twitter app that is available on GitHub). Check out his blog. Its devoted to “Ruby on mobile”, which as far as I know right now is basically just our technology. The first two articles very nicely summarize the development process with RhoSync and Rhodes, better than we did in the tutorial.

2 Comments | Posted by admin

The Seven Habits of Highly Effective Open Source Products

This morning I talked with Andreas Constantinou of VisionMobile who was pleasantly surprised that all of our source code checkins (”internal” and external) were available publicly on open source repositories (specifically the superb GitHub) and that our bugs and issues were also all publicly available (on the similarly excellent LightHouse). It seems like commonsense to me, that this is necessary to be able to claim that your product is open source. But, alas, many companies are not following such a process. For example, in the mobile space both Symbian and Android do NOT keep all of their checkins and issues available externally (nor do they really follow many of the habits listed below today, though I expect that to change). It’s great that those technologies are available under an open source license like GPL. But is that enough to truly say they are “open source”?

I was asked by Andreas what we believe is necessary to claim your product is open source. Here’s our take on the appropriate criteria, roughly in order of importance and prevalence in the industry.

1. public source viewing – Of course you need the source for your product to be publicly viewable and reviewable. Most products claiming to be open source meet this criteria at least on a release by release basis (whether this is sufficiently granular and realtime we’ll discuss below)
2. common license – you need to make it available under some prevailing non-company-specific open source license. For example, our product is available under Gnu Public License Version 3 (GPLv3). Making up your own license does not count. I’m a busy software developer. But I understand BSD, GPLv3 and other common licenses. If you make up your own license and I have to read it all, its not open source in my opinion
3. public source code checkins - all checkins need to be available realtime on a publicly available source code repository such as GitHub or SourceForge. No “internal company repositories” or even a publicly available source code repository hosted by the company themselves.
4. public bugs – defect reporting needs to be on a publicly available bug database such as LightHouse.
5. public forums – discussions and support should be available on a google group or some other publicly available forum. Lurking (for other users to learn) is good and should be encouraged. Few companies are doing this
6. anyone can contribute – contributions from the community are good and should be encouraged. For open source dual licensing companies (companies like ourselves that make a commercial license available for users who need one), a contribution agreement will almost always be necessary. But it should be brief and similar to others.
7. public complete and modifiable documentation – Specifications and user documentation should be publicly available on a Wiki that users are allowed to contribute. Almost noone does this now but it should be encouraged and I believe will eventually become the dominant model.

In all fairness, right now the list of companies doing all of these things is quite small. However, plenty of individual open source developers (probably the majority) follow these guidelines, mostly because each one is a win-win for getting as much done as possible with as few resources as possible, leveraging the power of the community. I believe the first four (viewable source, common license, public checkins, public bugs) should be an absolute requirement to label your product open source. The last three are very good practices that we think will become more predominant over time.

2 Comments | Posted by admin