A blog entry with a gracious nod to Gilad and Josh’s series of Java puzzlers.

Why does this code excerpt produce different results in the simulator vs running the app on the iPhone itself?

In my AllRides class which contains the information about all the club’s bike rides I have the initialization method below. In the ViewController for the preferences screen I then access and display the AllRides.club property.

AllRides.m:

- init {

}

Preferences.m (in – (void) viewDidLoad):

club.text = [[AllRides sharedRides] club];

When running in the simulator all appears well. The club name nicely appears:

When running the app on the iPhone the field is empty:

Changing the AllRides init method explicitly setting self.club makes both runtime environments behave the same expected way:

- init {

}

Suggestions? Answers?
I guess the underlying question is what the subtle differences are between club and self.club.

Matt Asay blogs that open source started small but is increasingly a play ground for the big companies. He goes on to write that small companies often connect with existing larger communities in order to reach scale while the big companies are able to kickstart a new community up to scale.

Both are true but the reasons or the results are perhaps a bit different than what Matt describes. One specific area where I believe there’s more to the story is when Matt writes that large-scale enterprises don’t need to worry about selling value (through their open source projects) because they already have profitable product lines that complement the open source efforts.

From my own professional experience I can say that this is often not the case.

The specific challenge that large companies have contrary to the small ones is exactly that: making sure that the open source efforts and the profitable product lines are indeed complementary. Many of the big companies start a particular open source project well after they launched their proprietary software products. In many cases big companies get into a particular open source project not because how it may complement existing offerings but through other means (it came with an acquisition for example) or for other strategic reasons.

Often the open source project will operate in a market similar to or very close to those that the existing products are addressing. Internal competition (for market share, for engineering resources, for marketing resources and so on) is inevitable if there is not a clear differentiating positioning of one vs the other. This battle is more likely to be damaging to the open source project and to the community it lives in. In these internal battles the proprietary products often have the upper hand as they bring in measurable revenue while for the open source project the contribution to the bottom line is often much more indirect.

A LinkedIn group I subscribe to started a discussion this weekend on recommendations: what is a good number to have, whether or when you’d hide a recommendation. This got me thinking in a broader sense about reputation: how do you establish and protect it, and how do different online communities go about it?

To start with LinkedIn, it has two main ways of establishing reputation: the aforementioned recommendations and the connections. Here it is very much “it is not what you know but who you know.” Status is derived from the number of connections one has and with whom one is connected. Behind both connections and recommendations lies the question of how many to have and how much is too much. For myself I like to able to say something comprehensible about a connection when asked so if I’ve had mainly some casual interaction with a requester of a connection then I am likely not to accept the invite. I know that others see LinkedIn connections much more similar to the exchange of business cards and thus apply a much lower bar. With recommendations I believe a strict management is appropriate. The value of a LinkedIn profile diminishes with an increasingly large number of recommendations. Aiming to have a few recommendations from select persons one has worked with communicates much more value to a profile.

The same principle applies regarding the recommendations you have written for others. A profile that shows a large number of recommended people then I do start to wonder about the objective judgment of that person: seemingly the bar is quite low. Especially since recommendations are typically written in rather glowing language.

An additional question in this weekend’s discussion was how much value one gives to recommendations when evaluating a person for example in the course of a job application. Here a number of aspects start to play. If I don’t know the persons who wrote the recommendations then it becomes harder to judge them. When looking at recommendations from the perspective of reputation then the main shortcoming surfaces: it is a one-way system, meaning that a person will – understandably – only display positive recommendations.
Read the rest of this entry »

The last number of years I have mainly developed software in Java for obvious reasons. Before that I’ve done C, C++, Algol 68, Pascal and some Cobol too. Recently I acquainted myself with writing software for Apple’s iPhone which of course takes place in the Objective-C language.

Language food fight
Like Java and C++, Objective-C builds on top of C in terms of its syntax. Unlike Java, Objective-C is a strict subset (or superset, depending how you look at it) of C: anything one can do in C, one can do in Objective-C. This is immediately the key material for deep, lengthy, philosophical debates – best done in a pub – whether this is Good or Bad. I think it is neither: the designers of both languages come at it from different viewpoints. Java imposes some rigidity on the programmer to protect against common mistakes in order to increase the programmer’s productivity. Objective-C gives the programmer all the freedoms of C plus object oriented programming concepts in order to increase the programmer’s productivity.

While both languages claim similar ancestry for their syntax, the outcomes are quite different thus as a Java programmer it takes a bit of time to comfortably read Objective-C code. Besides the syntax, one of the main differences between the two is how they treat null pointers. Let me give quick examples of both the syntax differences and the null pointer treatment.

I have a MapPin class which has this initialization method defined in the header file:

- (id)initWithCoordinates:(CLLocationCoordinate2D)location
                                placeName:(NSString *)placeName
                                description:(NSString *)description;

And here’s how it gets called:

MapPin *pin = [[MapPin alloc] initWithCoordinates:location
                                                         placeName:@”Start”
                                                         description:@”"];

Read the rest of this entry »

After long months of head scratching the EU at last approved Oracle’s acquisition of Sun Microsystems. James Gosling’s post captures the emotions perfectly.

It is sad to see the company go away but it never really managed to recover from the internet bust in 1999-2000 and then the financial crisis took away any hope that it still would so maybe this is the best outcome. It will be intriguing to observe what happens next. How will Oracle decide regarding Solaris/OpenSolaris, the SPARC business or rather the hardware business altogether, and of course Java?

Regarding the last one I am especially interested to see how Oracle will enjoy life sitting at the head of the table and now being the owner of all the various difficulties – compatibility, branding, open source, Apache, the Java ME royalty stream, JavaFX, etc etc – rather than one of the complainers (sorry Don). Oracle should have the ability to make some good decisions here; many that Sun always shied away from.

I also wonder what will happen with some of the great brains and personalities that made being part of Sun such a wonderful experience – people like James Gosling, Bill Shannon, Eduardo Pelegri and Jeff Jackson. Through the wonders of mergers and acquisitions many of the original JavaBeans team whom I joined in 1996 will be back together at the same company. I wish you all well in the months ahead while all the dust slowly settles.

Now I need to go and buy a t-shirt.

Just on my first day of playing with Eclipse I stumble upon Mike Milinkovich’s blog entry in which he seems to loose patience with a persistent criticizer of the Eclipse community.

I feel that I received much more explicit, ehhh, feedback when I ran the Java Community Process than Bjorn’s writings on his blog. But it seems there’s more history between the two gentlemen than just the exchanges between their two blogs and their comments. If nothing else Bjorn’s tag line for his blog is a hint. I admire Mike for speaking from the heart in his blog entry. During my JCP days there were certainly one or two times that I wanted to say to some to go away.

Yesterday evening I spent an hour or two reading Bjorn Freeman-Benson’s blog, Doug Schaefer’s blog and comments by Ed Merks, Mik Kersten and others. The tragedy of the commons features a number of times which is an inherent risk in any collaborative community: how to balance short term vs long terms needs, opportunity for one vs opportunity for all.

While there is clearly more water under the bridge between Bjorn and Mike I would argue that the existence of blogs like these are actually a measure of strength and health of the Eclipse community. That there is room and space for participants in a community to talk about what they don’t like and that they do indeed express this indicates the matureness in character of a community just as Mike’s airing of his irritation and his decision to keep such blogs as part of Planet Eclipse do.

It is tempting to have a philosophical exchange on whether building a software community is more of an art or whether there is science behind it. Matt Assay in his News.com blog writes that it takes time, leadership and fair amount of luck. I don’t want to dwell much on luck except to say that timing plays an important role.

Instead in this blog entry I like to talk about some of the tricks of the trade that I have seen be successful and also a few traits that don’t help your community along.

Many of the successful software communities share behavioral characteristics:

• Its discussions air different points of view – in other words participants feel free to speak up;
• There is a sense of belonging, an interest in helping each other;
• There is encouragement to contribute according to one’s abilities rather than in strict pre-determined places.

How do you get there?

Humans want to interact with humans.

Before all else participants in your community must feel, must know that they are interacting with peers, with named individuals within your organization rather than with functions (“Admin” or “Tech Support” or whatever) and are doing so on equal basis. You will want to let relationships develop. Early on the JBoss community did something simple and very effective: a slideshow on the home page of profile photos of community members and their location. Not only did it put names to faces, it also showed the geographical breadth. Many of us have experienced that dispersed team members interact much better once they have met face-to-face. For your online community find ways to emulate that.

Read the rest of this entry »

This entry was inspired by a delightful email conversation a short while ago with my peers, Rich Sands and Chris Andres.

The last number of years, communities seem all the rage (together with app stores actually). If a company develops software then it shall create a community. Already the term “community” is overloaded. While not daring to give a strict definition, I do want to attempt some delineation. The thing is not a community if it doesn’t:

• enable bidirectional, or rather multi-directional communication, and
• enable active and meaningful participation by those outside your organization, and
• foster some common activity.

In short, a mailing list or a newsletter is not a community. Yes, I have been in meetings where those were being argued as such.

Onto the topic at hand. Can the business of software communities be a commercially successful one? And then especially open source ones?

Well, yes, but you need to know why you’re doing it. Many communities, or rather the efforts of companies behind them, show signs that the goal of community has overtaken the purpose; a scenario so beautifully captured by the Underwear Gnomes episode of the South Park tv-show. Go look it up, it applies to very many situations. Creating an open source software community for the apparent sake of creating one, while possibly giving the company nice press headlines for a while, will not be an enjoyable experience over the long term. It creates confusion inside the organization and very likely causes the company to compete with the community or at least to view the community as a threat to its business.

This perception of competition, especially in the case of open source software, is often caused by the temptation to see the community as a self-standing business and then applying a P&L to that business, comparing it to other lines of business the company may be in leading to debates whether the community business positively or negatively impacts the existing, traditional business. While it can be true that the community really is the business, in most cases a company starts a community in support of its commercial prospects. In other words to expand the business overall rather than the community being the commercial prospect itself.

Meaning that the community is a marketing tool. And thus any return on investment should be evaluated by the company in much the same way it assesses its ROI on other marketing and PR strategies.

I am curious how many readers I lost at this point with declaring open source software communities as mere marketing tools of corporations…

Read the rest of this entry »

Community Leadership Summit, San Jose, July 18-19 2009.

A so-called unconference and the brainchild of Jono Bacon of Ubuntu fame, it brought together community leaders, managers, aficionado from across the software and computer industry as well as a few others like the music industry. A great opportunity to meet with like-minded spirits and reconnect with ex-colleagues and friends.

As it was an unconference the sessions and discussions were very much whatever we wanted them to be: for example Saturday’s schedule. Each morning at the plenary session people would stand up and give short descriptions of the topics they were proposing. This could be whatever one wanted to talk about, ranging from “Quality Assurance in communities” to “How do you describe what you do?” (the difficulty of explaining your job to your parents, a familiar problem).

In this style of conference sessions are very much discussions. You sit in a group and the group very much dictates where the topic goes. Couple of my favorite sessions covered how to balance the interests of the F/OSS community at large versus the corporate interests of the community owner, how to build your user/developer community and finding metrics that matter. These and other sessions had common recurring themes – two specifically that I want to explore here further: the science of community is still relatively new, and community should be looked at as business as usual.

To start with the latter, this came up in the “FOSS community & business” session led by Louis Suarez on Saturday, in “Building your user (developer) community” moderated by Pati Dock on Sunday, and in “Metrics that matter” also on Sunday. In the first session OpenOffice.org was discussed to some extent. Sun started this effort not necessarily to build market share in the software productivity market but more to cause some distraction (perhaps just PR-wise) for Microsoft. While this motivation may be a little tough on individuals (and Sun’s employees) participating in that community, I believe from the corporate perspective this is a legitimate reason to start and run such an effort. The key aspect being that senior management has a clear understanding of the purpose. In any case community leader will continuously need to educate and reconfirm his or her company of the community’s mission and its value to the company. There will always be tension between functions such as sales and those active in the community.

Read the rest of this entry »