The “Assembling the Android army” series of posts is where I provide completely unsolicited advice to Google and the Open Handset Alliance on strategies and tactics for growing the base of Android developers, to better cement Android’s place in the mobile platform marketplace.
One of the key areas of interest among Android developers is the “soft keyboard”. While the hardware keyboard of the T-Mobile G1 has been one of its strong selling points, it does not cover every scenario:
Sliding the keyboard in and out can get tedious for applications designed to be used in portrait mode, so having an on-screen pickboard option would be handy
Not all Android devices will have hardware keyboards, including some devices that Android is being ported to today, such as the Neo Freerunner
Not everybody is comfortable with an English-language QWERTY keyboard
Not surprisingly, a handful of people have popped up on the Android source code Google Groups, trying to figure out how they can add soft keyboards that can work across all applications, not just those who specifically incorporate soft keyboard code. The reaction from the core Android team has been: “we” are working on a framework to support multiple input methods and when “we” are finished you can work on offering input methods of your own creation built atop this framework. This, of course, is the same sort of reaction the community got to these sorts of questions since Android was launched a year ago.
There’s just one difference: Android is now open source. Ideally, the definition of “we” should change to match it.
Open source and collaborative development, to quote a long-abandoned ad campaign, are “two great tastes that taste great together”, to the point where many people assume that open source implies collaborative development. That is far from the case. There are industry consortia, or even far-flung offices of a single organization, that practice collaborative software development without adopting open source licenses. More importantly, there are plenty of examples of corporations who slap an open source license on some code, “throw the bits over the wall”, and never engage in collaborative development — Linux device drivers sometimes follow this pattern.
The Android project has some of the markings of collaborative development, from a well-documented patch process to a roster of project roles to an open source code repository. Collaborative development needs those structures, but those structures are not sufficient to create collaborative development.
In the end, collaborative development is mostly about culture.
This is why it is so hard for closed projects to open up, compared to an equivalent team starting as open source from the outset. The closed-project team is so used to “we” meaning the team — and only the team — that it takes a while for “we” to start to encompass “outsiders”. The closed-project managers may be slow to realize that they will need to accept a short-term productivity loss as they devote engineering time not to slinging code, but to helping others start to sling code. And the corporation may take quite some time to understand that internal communication tools, while highly productive for closed-project teams, are poison to collaborative development, and so teams need to be forced into the public realm for their discussions.
Projects that fail to change their culture will have the effect, if not the intent, of “throwing bits over the wall”. This is not necessarily a death-knell for projects. It is, however, going to frustrate a lot of people who expect that open source means collaborative development. And, it is going to inhibit community participation in the project at all levels, as the proprietary “we” attitude trickles through to all facets of the project-community relationship.
For Android to succeed, I feel it needs to truly embrace collaborative development, including on the platform itself. This is not a matter of using the sexy-new version control tool, or upgrading the issue tracker.
It’s a matter of culture. It’s a matter of “we”.
