Once More unto the Breach

Berkus's Ten Ways to Destroy Community and Bacon's Art of Community

This was a great week for reviewing "community building" resources in my world. I discovered Josh Berkus's recent Java One presentation, "Ten Ways to Destroy Your Community", and I received my reviewer's copy of Jono Bacon's "The Art of Community". [srw — I was a pre-publication reviewer for Jono.]

Berkus's presentation is absolutely brilliant. After pointing out very tongue-in-cheek why your community is such a painful group of people (e.g. "They mess up your marketing plans by doing their own marketing and PR" or "They mess up your product plans with unexpected innovation"), he proceeds to give you a perfect run down of ten ways to be rid of them with excellent examples. In order:

1. Difficult Tools
2. Encourage Poisonous People
3. Don't Document Anything
4. Closed Door Meetings
5. Lots of Legalese
6. Bad Liaison
7. Governance Obfuscation
8. Screw Around with Licences
9. Stop Outside Committers
10. Be Silent

The sad part of this list is how true it is. While Josh picked examples from his experiences, too often you visit a site to evaluate a company-led (or consortia-led) open source project to find too many of these counter principles in play.

Jono's book was published last Summer. His lyrical metal prose conveys his brilliant experiences over past years in community involvement, then community development, culminating in one of the best led community examples around Ubuntu. While Jono's eleven chapters don't align neatly with Josh's ten weapons of mass distraction, there is method and madness to attack each of the problems (or hopefully to avoid them altogether).

1. Difficult Tools [Chapter 5]
2. Encourage Poisonous People [Chapter 9]
3. Don't Document Anything [Chapters 3-5]
4. Closed Door Meetings [Chapter 3,4,8]
5. Lots of Legalese[Chapter 8]
6. Bad Liaison [Chapter 11]
7. Governance Obfuscation [Chapter 8]
8. Screw Around with Licences [Chapters 1,2,8]
9. Stop Outside Committers [Chapters 4,8]
10. Be Silent [Chapter 3]

If you need a quick litmus test to check on your community, read the presentation. Once you [honestly] suspect there may be a problem [or two], dig into book. Enjoy.

Making Money from Open Source and the Business Model Debate

Matt Aslett makes great observations about open source business models in a recent blog follow-up discussion:

I am very glad that they took that decision, because in hindsight the statement “there is no open source business model” would have been inaccurate in the context of our report. We identified that there are multiple models used to build a business around open source: theoretically hundreds.

The 451 Group did a lot of research as they developed their model of discussion, and their definitions around development model, license choice, and revenue trigger are great. But it still feels like they start falling victim to the shades of grey slicing problem.

I'm still more of a fan of the tool analogy. As a company, you have a certain budget to spend developing the product, it's marketing, sales and distribution. Imagine a proper old hardware shop where you have a certain budget and need to figure out how you're going to spend to buy what tools from which aisles (development, marketing, sales, legal) to launch and build (and maintain) your product. "Open source licensing" is a set of new tools in the legal aisle and "collaborative community development" is a new aisle. It's not that there are hundreds of business models, but rather one can combine the tools in hundreds of ways. (Some ways are more proved than others depending upon the business.)

Indeed, "dual licensing" doesn't even belong in the open source licensing tools. It's an attribute of copyright law. I can license my intellectual asset to as many people as I want in as many ways as I choose. The Microsoft EULA attached to software at the local office supply store is different to the Enterprise Agreement signed when a corporation purchases based on a bundle of units and services is different again from a volume license to a smaller organization. No one accuses Microsoft of "dual" or "multi-licensing" their software. The fact that MySQL began closed licensing royalties as well as selling service agreements subscriptions (i.e. product) of their GPL distributed software does not mean that they invented "dual licensing".

The fundamental question around which this all revolves is the confusion embodied when one asks, "How can you make money when you give the software away for free?" Large "software" companies (Microsoft, SAP, Oracle, Adobe, etc.) have spent a lot of time questioning the scale of "the business model(s)" rather than looking at the opportunities the tools provide. In the end, they need to understand that it's not the "software" that a customer is buying but the solution and the support and maintenance and certified tested warranted removal of risk embodied in their product packaging and testing capabilities. (This is a core competency Microsoft has over most "software" companies when you consider the size of the test matrix defined by OEMs, ISVs, and device manufacturers that needs to be exercised between code complete and release-to-manufacturing.) Whether you call it a "license" fee and then charge 20% of the license fee per year for maintenance, or distribute the "license" fee into the maintenance "subscription" over time isn't a discussion about open source. It's just business.

Open Source Software and Product Management Tools

Matt Asay has a great blog post today on what Alfresco has learned with regards to their use of open source and product management, from both the perspective of their own product development feedback, as well as the strength of reuse by their customer base.

For years, our marketing has targeted buyers in these markets, pitching a low-cost, high-value alternative to proprietary ECM/WCM/RM.

Our customers didn't get the memo. While we were talking about ECM, many of the roughly 30,000 people downloading the product every month were using it as a foundation upon which to build their own applications, most of which would never be classified as ECM. They were creating their own category of infrastructure/middleware, using our technology.

The content application server was born, and we almost missed it, despite the fact that it was happening with our code. We were so busy marketing our vision that we almost missed listening to our users' vision(s). This new vision on an old way of using our product will significantly impact everything we do for years to come.

This is the sort of strategic edge I meant yesterday when discussing the extra tools a product manager has when open source software is added to the mix. Matt also points off to Vinnie Mirchandani's posted observations on how mainstream IT is rediscovering custom-built applications again. (Indeed it was exactly this sort of rationale coupled with open source software that was the impetus for the creation of Optaros in 2004 and why I went to work there.)

It really is about the engineering economic imperative of collaborative community development coupled with free and open source software licensing and enabled by the web and its ability to remove friction from the process. Developing good software is hard work, and we have shared software literally since we've been writing it. Brian Behlendorf gave a great talk around the time I began this blog where he made a number of key observations about open source repositories based on his experience. Open source projects don't "end" the way traditional development of IT applications end (sliding into withering maintenance) or vendor-led software products (being replaced by forced upgrades). Well run open source projects are much more organic. The software evolves and adapts. The building blocks are continually improving and very complex and powerful platforms can be constructed.

Carlo Daffura responded to yesterday's post with pointers to two posts supporting the idea of the economic value of open source software in product development. This certainly bears out our experience from 1995-1999 developing Interix (now Services for UNIX at Microsoft). Following one of Carlo's examples, Ari Jaaksi's paper is a fantastic overview of Nokia's experience launching the N770 and the cost savings to be had.

I essentially said yesterday that it's all just software business, that there is no "open source business model". Please don't misunderstand me. Open source licensed repositories and collaborative community development on the web substantially add to the tool set of product management on both the marketing and engineering sides of the house.

My New Android Phone and AT&T Wireless

I was lucky enough to get one of the new unlocked Android developer phones from a friend at Google to keep me occupied. There are pictures here:

www.flickr.com

I'm an AT&T Wireless customer. I wandered into the store to ask if there were problems, and was told they didn't know. (I added the unlimited data plan for US$15/month while I was there, being ever so hopeful.) A quick Google about and I came across a post that pointed out the following settings (for AT&T and many more mobile operators):

Name: AT&T
APN: wap.cingular
Proxy: leave blank
Port: leave blank
Username:[email protected]
Password:CINGULAR1
Server: leave blank
MMSC: http://mmsc.cingular.com
MMS Proxy: wireless.cingular.com
MMS Port: 80
MCC:310
MNC:410 (note. this could also be 310, 41 or 15)
APN Type: leave blank


Create the access point name (APN) from the Settings App->Wireless Controls->Mobile Networks->Access Point Names (hit the Menu button to bring up "New APN"). I selected the newly created AT&T APN and I was up and running.

Everything seems to work so far. Calls, SMS, MMS in/out all work. Need to spend a bit more time with the apps. The stock apps for Gmail and browsing and messaging seem fine. I'm learning to hit the Menu button when stymied about what to do next and it's not obvious. That typically brings up the options for which you were looking. I've loaded Twidroid from the Android App Store along with a few other tools (because everyone needs a command-line window and a telnet client on their phone).

The only thing proving really onerous is Google assumes I have my contacts on GMail and won't read anything from the SIM apparently. The synchronization between my old mobile phone (a Motorola Razr) and my desktop (a Mac PowerBook G4) is horrendously bad. So I'm needing to hand rationalize a lot of phone numbers. Tedious, but an opportunity to clean out the list. I'm going to go fix that problem more broadly soon regardless.

Now to download the Android SDK.

Does Your Community Manager Report to Engineering or Marketing?

I asked a question during Matt Aslett's excellent presentation on Monday at the Microsft/SD Forum OSBC Zero Day event: Does your community manager report to engineering or marketing? Matt gently stepped out of the way, but there is exactly one right answer: Engineering.

Here's why:

Community is concerned with the software project and it's complementary assets. Customers care about buying product solutions to their problems.

Engineering cares about software development. Marketing cares about product lead generation and qualification.

Engineers manage software. Marketing manages messages and expectations.

This doesn't mean that the community isn't an enormous source of word-of-mouth evangelism for the company, the project brand, and self-qualified leads over time. But the community doesn't want messages and they don't want to be qualified or converted. The community is already setting their own expectations around the project instead of buying the product. Neither does this mean that marketing is out of the loop at developing inbound requirements from customers for the engineering team as they develop the software that feeds into the product.

While marketing traditionally managed the "developer network" in closed source companies, that's because the software wasn't a community engagement mechanism for users that weren't customers. Growing the developer community around your platform was a marketing function based on the business strategy of growing market share and providing complement value with lots of "knowledgeable developers" for customers. The software part of the solution wasn't a source of customer contribution, innovation, and testing resource. Your community equated to your customers.

There are companies that historically have strong product management departments that are often staffed by engineers that have crossed the floor to marketing. There's still a problem here with the community manager reporting to marketing, because the marketing department is traditionally measured on marketing functions. They will behave against how they're measured.

So community development and management is an engineering function.

Ohloh Open Source Directory Passes 250,000 Projects

Ohloh announced yesterday that they now provide information and statistics on more than 250,000 free and open source software projects in their directory.

I have long believed that consumers of open source (users and buyers alike) don't want to buy "accredited" aggregations of open source. (Yes — I appreciate many CIOs say something different dressed in statements using "one throat to choke" but it's not what they do.) Red Hat, JBoss Inc, and MySQL AB all demonstrated over the past decade business execution based on being the "best" most focused provider of a critical piece of software. It wasn't simply their technology prowess, however, but their message to the market was equally sharp, clear and understandable, and their community engagement and commitment was obvious and well defined. When you consider other things that might reasonably be bought by an enterprise, you can see Alfresco's corporate growth here as well.

When a potential open source user wanted to find out "what open source software is available" to solve a problem, they were invariably left hunting across Google, SourceForge, and sites like java-source.net and FreshMeat. There was no consistency. The depth of information was sketchy. Some of it was bleeding edge software, some tied to the site. There was no sense of "what's good" unless you were already involved in a particular community, and even then community bias could get in the way. This gave way to a collection of directory solutions and companies that tried to bridge this gap.

Ohloh has always had the most useful and interesting directory for me. First, they have no direct sales model tied to the directory, so my trust in the depth and breadth of the information is high. Second, the beauty of the analysis is that the core data is metrics based on what programmers do, not what they say. I can see how big or small a community is, how long it's been around, how active it is, and this provides hard data when one then looks at the qualitative commentary. Third, it's always been comprehensive across the open source world and getting better all the time.

Ohloh summary view of the Eclipse Project

Over their several year history, they have continued to expand and add features to their core statistical analysis. They've built the community and expanded the number of repositories they support. Once one finds a project, one can see other projects immediately that are related through the tagging and stacking other Ohloh users share. The site is a proper social network for open source developers. It's been used to get a project manager's view of an open source project by the project's own leadership. As a resource for job hunters and recruiters it's invaluable to be able to see the visual resume of a developer. They've evolved their offerings to act as download host, and provide job and support services classifieds.

Over time Ohloh has also provided an API and interesting gadgets to add to project webpages, including the language calculator:

The code calculator (based on the COCOMO model):

And the overall statistics:

The Ohloh directory and community continues to get better and better as it evolves and matures. Congratulations on reaching the quarter million project mark!

Other data views from the Ohloh directory:

Disclaimer: I have done work for Ohloh in the past. I continue to act as an advisor.

Mindtouch, Dekiwiki, and the New New Application Development in Enterprise IT

"A PHP interface to a web services layer that allows users to federate and orchestrate functionality from other services, applications, and data stores." That's how Damien Howley, Mindtouch evangelist, described the current DekiWiki release. I was spending a couple days on the show floor at ZendConf helping Bitrock who had a pedestal in the Microsoft booth. Mindtouch had the pedestal next to us in the booth, and during one of the slow periods on the floor Damien gave me a demo of their latest technology.

I wasn't going for it. It's an open source wiki, developed by MindTouch who then provides enterprise support. I'd seen the demo a few years ago, and it was essentially some nice touches on a wiki for the enterprise user like a good WYSIWYG editor. Then Damien gave me the new demo. Mindtouch has added Dekiscript as a programming language within Dekiwiki. Think Javascript added to HTML pages and dynamic content development only applied to wiki pages. Now I'm NOT a wiki sort of guy but I couldn't help to be amazed by what I saw.

I wanted to explore the idea of what this might mean for enterprise applications development a little more. I signed up for a free account on their Deki On Demand hosted service. (These free accounts no longer exist.) It took me a few minutes to get going with the user guide, and I thought I'd try something simple like pulling together a dynamic "bio" page. I grabbed content from my existing bio, and then using the WYSIWYG extensions environment, I quickly added the embedded DekiScript extensions for photos from Flickr, the last few blog posts from my feed, and a Twitter widget.

So the following fragment from the page:

Recent Photos: 
{{ flickr.Badge{tags: "Stephen Walli"} }} 
Recent Blog Posts:  
 {{ feed.List{feed: "http://feeds.feedburner.com/OnceMoreUntoTheBreach", max: "6"} }}
Recent Tweets:
{{ twitter.current{name: "stephenrwalli"} }}

Produces the following:

There's a complete security model embedded in the wiki as one would expect. There's support for writing your own templates, and site wide CSS, etc. There's support for writing your own extensions (and sharing them in the developer community). There are also large scale adaptors (e.g. SugarCRM, Microsoft SQLserver). So this is where it gets interesting. How fast could an enterprise IT developer with a little Dekiscript knowledge and the toolkit of extensions and adaptors start to build interesting applications. I don't mean a more interesting content management system. I'm thinking of complex content-centric multi-departmental work-flow environments like patient or legal case management systems. Is it still enterprise IT development if they install DekiWiki and develop dashboards with some simple scripting and drag-and-drop goodness? How soon before enterprise business people step around the IT department to do their own "development"?

Mac Django MySQLdb Problems and Bitnami Love

I have an idea for a web property and wanted to explore Django as a way to create a prototype. I grabbed the two basic Django books and they each take you through the "how to install Django" bit. They start the discussion about setting up MySQL (assuming of course that you remember how that works), and then they each get to an innocent line that effectively says: You'll need the Python MySQL package (MySQLdb).

Now the fun begins. There's sometimes a wee bit of a problem building it on a Mac due to a confusion between 32-bit and 64-bit and PPC and Intel and which MySQL and which Python you might be using or have installed. I learned this much by poking about for awhile on Google. It took me a bit to realize I hadn't updated my developer Xtools world when I upgraded to Mac OS Leopard so that I was at least seeing the errors that others have reported. [The best summary is here if you want to do this the hard way.] A friend cautioned me around messing with the stock MySQL and Python worlds on the Mac, as it's a good way to make the shipped tools unusable if you don't get the builds right. I'm now a couple or three hours into the problem.

Then I have a brilliant idea. I'm an adviser to Bitrock, and on Bitnami they support a large collection of open source technology packages for Windows, Linux, Mac OSX (and Solaris). The packages are single-click installers that deliver the open source technology and all of its dependencies. The technology is installed in separate trees such that they do not interfere with the stock installed Mac packages. (There are easy ways to combine the packaged technologies if you don't want multiple instantiations of MySQL, Apache, etc.)

Sure enough, there's a Django stack for Mac OSX. A few minutes of download, a few minutes of install (and the autoconfiguration prompts for MySQL user setup before the install), and it's time for the big test. But wait: there's even an executable file in the install root called use_djangostack that seems to set my environment correctly. NOW it's time for the big test:

/Users/xxx> /Applications/djangostack-1.0-6/use_djangostack 
bash-3.2$ which python
/Applications/djangostack-1.0-6/python/bin/python
bash-3.2$ python
Python 2.5.1 (r251:54863, Sep 11 2008, 12:40:30) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>> 
bash-3.2$ python /Applications/djangostack-1.0-6/apps/django/bin/django-admin.py startproject testproject 
bash-3.2$ cd testproject
bash-3.2$ ls
__init__.py     manage.py       settings.py     urls.py
bash-3.2$ 

That was a lot less painful than any of the alternatives. Now I can get back to exploring Django. If you want to explore open source software technology in a sand box or easily set up an application like WordPress, Joomla, Drupal, or MediaWiki, I would encourage you to take a look at Bitnami. There's lots of goodness hiding there.

Caution: There was one other small configuration issue I needed to make in the next steps of configuring and synchronizing MySQL not covered in the books or [yet] in the README.txt file, and that was to ensure your Django project settings.py file contains:

DATABASE_HOST=[Django stack install root]/mysql/tmp/mysql.sock

Nokia and the Symbian Foundation Opportunity - Part II

The previous post looked at the Nokia acquisition of Symbian from the competitive perspective. Let's now look at the opportunities and challenges for Nokia and the new Symbian Foundation. Remember that assuming successful regulatory approval, there will be no Symbian Ltd. anymore. Nokia will need to manage the challenges that come with any acquisition. When you buy a company, you essentially acquire the assets (in this case the software), the intellectual capital of the employees, and the customers.

This acquisition is particularly interesting as key Symbian Ltd. shareholders and customers have banded together to deliver the primary software assets into a not-for-profit organization. There's a great white paper outlining the initial strategy on the currently minimalist Symbian Foundation site.

Essentially:

• Nokia will acquire the remaining shares of Symbian Ltd. that it doesn't already own.
• Symbian Ltd. employees become Nokia employees.
• Fujitsu, Motorola, Nokia, NTT DOCOMO, and Sony Ericsson (all Symbian Foundation board members with the exception of Fujitsu) will contribute SymbianOS, S60, UIQ, MOAP and related software and documentation assets to the newly formed foundation.
• The initial board directors will be AT&T, LG, Motorola, Nokia, NTT DOCOMO, Samsung Electronics, Sony Ericsson, STMicroelectronics, Texas Instruments and Vodafone.
• The foundation launches (expected in early 2009) and all the assets will be available to members under a royalty-free license.
• A new platform will be developed from SymbianOS and S60 with selected components of UIQ and MOAP. The first release of the unified Symbian Foundation platform is expected to be available during 2009. The platform will offer the means to build a complete mobile device while providing the tools to differentiate devices through tailoring of the user experience, applications and services.
• The new platform is to be backwards compatible with SymbianOS v9 and S60 3rd Edition.
• Platform assets will be made available as open source gradually over the next 2 years, with the intent to use the Eclipse Public License (EPL) 1.0, making the platform code available to all for free.

Most of this is fantastic news. The economics of code sharing, value preservation of the intellectual asset, and innovation capture will be delivered through the foundation with the primary stakeholders sharing the costs. This is a perfect example of the economics of shared development in this particular market space and "why open source software."

Organization and governance of the new Foundation will be key. The foundation is open to all and membership will cost US$1500. The primary board members will share all the operational costs. This seems a reasonable way to manage the cost — it's likely much cheaper than historical royalty payments and it scales well versus a fixed premium membership fee structure seen in other places. The white paper describes the functioning of the foundation based on the following structure.

As a side observation, it would behoove Intel to get involved early on, conceivably as a primary board member and share the costs. As the mobile world of phones and laptops converge, they should be investing beyond moblin.org. That is NOT to say that the mobile world will be a single class of devices in the future, but rather the space will overlap for some time and I would think Intel would want to participate as widely as possible.

So where are the edges that need to be carefully considered in the new Symbian Foundation?

• While the foundation is open to all, and the list of membership benefits is well defined today (in the white paper), one of the benefits reads: Right to access and modify foundation source code, and contribute code to the foundation. This needs to be rethought along the lines of how the Eclipse Foundation manages committers and contributors. The Symbian Foundation is deliberately cutting off unknown sources of contribution if they make it a membership benefit. There is no loss of control in encouraging (and vetting) contributions from as wide a population as possible. Putting gates around the community early, or discouraging contributors looks arrogant and risks the community's participation and growth at precisely the time when it is most needed. Microsoft certainly demonstrated how fast you could pour cold water on a community with the Rotor project. Motorola had its early Linux community vanish. Heavy-handed control and "we know best" attitudes hampered the early critical growth of the OpenSolaris community. Who knows what sources of innovation will be cut off (and will defect to other projects) with this gate in place.
• "Backwards compatibility" as an absolute goal. This is not a bad thing per se, but it feels like the backwards compatibility requirement exists to deal with a long delivery cycle — essentially asking developers to begin developing today for the open source platform delivery in two years and the promise that the investment will be protected. All complex dynamic software hits a point in its evolution where a re-write is required. (The Linux kernel rewrote the entire VM and scheduler after about 10 years of evolution with modern architectures.) Backwards compatibility becomes the challenge. But the opportunity forward MUST be bigger than the backwards compatibility option. It needs to be managed in the community, i.e. this is a community issue and a delivery time-line issue. Think of the opportunity that Microsoft took moving from the Windows world of the late nineties to the new world enabled by NT. Think of the enormous opportunity Apple took moving from Mac OS9 to Mac OSX. Think of developing a community of innovation forward like the Mozilla world and Eclipse.
• The whole two-year process feels like a traditional corporate engineering culture trying to manage change around a well established product space. This would be great if this was what Symbian Ltd. was to remain (but even then it risks being a dead-end overtaken by other solutions with the coming mobile Internet wave). When IBM began the Eclipse Project, they put safe IP structures around a software base, some simple governance and a road map in place, and got on with the work. Later, the Eclipse Foundation was created as a better way to manage the inbound innovation and growth under a well defined IP regime. Now, the Eclipse Foundation and Mozilla Corp. provide excellent blueprints for what the Symbian Foundation needs to be. Nokia already has the inhouse experience to build from those blueprints. Engineering cultural change is difficult but essential here. While one wouldn't expect Symbian Ltd. to release its core assets while awaiting regulatory approval, there have to be other complementary software assets internally available that could be released as early experiments to begin to get the IT structure in place and begin the cultural learning. Two years gives Android and LiMo and even Windows Mobile too much time to erode a community that should rightly be coming to the Symbian Foundation.

These are all key issues. Cultural change is hard in any acquisition. In this case it is doubly so for an engineering team used to delivering to a particular set of customer requirements now dropped into an open source world and needing to understand how open source works and customers and users differ, as well as for a business team used to driving platform revenue and profitability that need to consider now driving platform adoption as an end goal unto itself.

The Symbian Foundation is an opportunity not to simply re-invent the mobile phone platform, but to build the most innovative shared platform forward for the coming mobile Internet. Working with peer organizations like the Eclipse and Mozilla foundations, and arguably the Android project, a stable dynamic open source platform can be created that best suits the needs of customers and consumers for some time to come. Nokia's vision and foresight open up amazing possibilities. Here's wishing them speedy success.

EclipseCon 2008 Open Source Software Business Track

Donald Smith has a dilemma. Over the years, EclipseCon has built a premier event for the Eclipse development community. With the success of the Eclipse Foundation, and the growth of the number of businesses built around and upon the Eclipse technology base, the Foundation has been building out the business track at EclipseCon as well. And herein lies Donald's dilemma — no one knows about the business track.

This year promises to be better than ever. Brent Williams is returning. (Last year at EclipseCon Brent gave what I believe to be the best talk on software businesses ever.) R0ml is returning. Donald outlines highlights of the business track in a blog post here. The full schedule and registration site is here.

If you're doing anything from a business perspective with Eclipse, whether building tools or contributing to the technology base, EclipseCon is the place to be.