Once More unto the Breach

Open Source, Software Development Futures, and Monki Gras 2012

I had the pleasure of attending Monki Gras 2012 last week in London, UK. It is a fabulous small conference and that will always be it's challenge. (More on this in a moment.) Monki Gras was probably the best small conference I've ever attended. It was ostensibly a conference about where we're going in software development, tying it back to ideas of craft over industrialization. Following along that theme, we had craft coffee for the breaks, craft beer in the reception and as a tasting at dinner, and enjoyed craft food at the breaks and lunch.

The presentation content, however, was incredible. The format was "short" talks lasting 20-30 minutes. It worked well, allowing lots of time to talk amongst the participants. There were ~150 participants and speakers and this was a perfect size. Over the two days, I walked away with something new to think about from almost every single talk.

Some highlights for me included (and I'll post slide references as I received them):

• Excellent observations from Matt Lemay (@mattlemay) from bit.ly on "What we share is different than what we click". Best quote: "We've had social media for long enough to be embarrassed by ourselves."
• Matt Bidulph (@mattb) talked about new ways to consider social media data analysis and presented ideas for the "Place Graph" alongside the "Social Graph" (see pictures below). In a question: What is the Holborn of Amsterdam? Or the Williamsburg of London?
• Laura Merling (@magicmerl) walked us through a great introduction to the idea of the "craft telco" building on the history of the telco space, and comparisons to the brewing industry from pure to industrialization to craft. (Think Twilio.)
• Kohsuke Kawguchi (@kohsukekawa) talked about developing developer communities from his experience in Jenkins and the idea of a developer pipeline (analogous to customer pipelines) and how to get developers qualified through it by making everything relentless easier. Slides here on SlideShare. This talk was a great complement to my blog post on software development discipline and developing communities. I also blogged Kohsuke's talk separately on the Outercurve Foundation blog.
• Jason Hoffman and Bryan Cantrill gave an enormously entertaining "Doppelbock" talk on the differing roles of CTO and VP, Engineering with some wonderful anti-patterns. Slides here on SlideShare. Best quote from @bcantrill, "Process doesn't write software."
• Zack Urlocker (@zurlocker) gave a great talk on considerations for distributed product development practices.
• Mike Milinkovich (@mmilinkov) also gave a great talk on the relevance of foundations in an open source world. (There was a broad debate on the subject back in November 2011.)

Those were my highlights from Day One in Conway Hall in Bloomsbury. Okay, I also had the Best Espresso of My Life from the Barista-for-Hire. And the beer tasting at dinner led by Melissa Cole was also awesome.

Day Two moved us down to Rich Mix, an equally interesting and completely different venue in Shoreditch. The talks were equally brilliant. My top picks:

• Gavin Starks gave us great insight into developers and apps driving social change at amee.com. Very cool example of Autodesk integrating with the AMEE environmental data feeds to allow designers to model carbon footprints of designs while still designing, rather than discovering the cost in manufacturing.
• Paul Downey (@psd) talked about hardware forks and gave us a view of solderpad.com (@solderpad). (Think git for hardware developers only better — very cool.)
• Donnie Berkholz talked about how much assholes cost projects with examples from the Gentoo world. (They lost 20% of their community from trolls and trouble makers and they NEVER CAME BACK even after the asshole problem had been solved. That's how expensive it gets.)
• Dave Neary (@nearyd) gave a great introduction into how to develop developer communities from a different perspective to Kohsuke, but again emphasizing the need for detail and craft. He built on ideas of mentorship and apprenticeship and examples from the world of Go. (Ask him about the design of Go boards sometime if you want to be blown away by craft.)
• Joe "Zonker" Brockmeier (@jzb) introduced people to ideas for promoting their projects with the press and some insight into the world of tech journalists being pitched by PR. A very good how-to with slides here on SlideShare.
• Leisa Riechelt (@leisa) gave a wonderful talk on "Why most UX is Shite." Her [excellent] notes are up on her blog with a link to slides.
• Finally, Irene Ros (@ireneros) and Alex Graul (@alexgraul) gave a great presentation on what makes good data visualization and how subjective it can be from both the presenter and observer perspectives.

There were a number of great observations flying around the twitter verse during the conference but two bear repeating:

#monkigras is a new kind of conference where the participants are equal to the top calibre speakers

— alexis richardson (@monadic) February 2, 2012

And from Matt Lemay, one of the speakers:

Unsurprisingly, @monkigras was a tremendous success. This will be the future model for many, many tech conferences. This is a *moment*.

— Matt LeMay (@mattlemay) February 1, 2012

And therein lies the challenge. It was the perfect size at ~150 people. It wasn't an invite only event so there was a wonderful mix of people. Smaller would have been fine, but bigger and it will lose some of the sense of intimacy and informality that makes the side conversations easy and important. (One person observed that the U.S. event last Fall was more interactive. I've heard of that difference between the U.S. and UK at similar sized events in the past.) I believe James Governor did design the agenda, asking speakers to give specific talks and I've seen this work really well before (Transfer Summit/UK) at bringing an underlying sense of coherency to a small conference. It certainly worked brilliantly well at Monki Gras. Pairing the event with craft beer and craft coffee also worked in ways I didn't imagine.

All in all, a brilliant conference. Redmonk hopes to have all the filmed talks online soon, and I'll update a link as it becomes available.

Update [15 Feb 2012]: I have also written about three perspectives on the care and feeding of development communities on Network World based on three talks given at the conference.

www.flickr.com

Coffee Houses and Code Communities (and other Network World blog posts)

I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the discussion around open source community, business, and IP management

• Of Coffee Houses and Code Communities
  We can learn a lot about successful community building from Starbucks
  Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident and it differentiates between the co-creation of the asset and the co-production of the community.
• Makers, Users and Buyers of Open Source Software
  Understanding your relationship to a project lets you ask the right questions.
  More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance. I try to frame a participants relationship to a project so they can best understand what they do (and don't) need to care about.
• How to Talk to Your Lawyer about Open Source Software
  Lawyers know surprisingly more than they think about open source software.
  If you’re a developer that wants to use free and open source software then sooner or later you’re going to need to talk to a lawyer. Many developers have a working understanding of software intellectual property, but unfortunately software copyright is a space fraught with exceptions and edges and ambiguities. Karen Copenhaver came up with a great way to explain open source to a lawyer, and I managed to find the recording of it again.
• It’s Not That Complicated
  Too much is being made of FOSS licensing complexity.
  We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. I'm tired of it. It's just not that complicated to maintain a clean IP environment in software development.
• Please Don’t Confuse Standards with Open Source Software
  While standards and FOSS may overlap, they can’t be merged into one mega concept
  Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community.
• Open Source: No one is working for free
  To understand the economics of open source, look to the R&D of collaboration.
  People continue to wonder how to make money in the free and open source software world. It’s dressed up in discussions of how one makes money when you give away the software for free, or why developers are working for free. It can likewise lead to a management backlash of not contributing to FOSS projects because some think their developers are working on FOSS instead of their own work. I take another run at explaining why the economics is in a business's best interests.
• A FOSS project isn’t necessarily a software product
  For FOSS the question isn’t just build vs. buy but also borrow versus share.
  Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? Fedora? CentOS? Should they use the community edition of the Alfresco content management server or buy the product? How does one judge the “software” and whether it’s “right” for one’s business? These are all questions that confront developers and IT managers as they encounter the FOSS world. I try to tease it apart for people so they understand the difference between a product for sale and an open source project.

Enjoy!

The Linux Foundation Announces the Open Compliance Program (on CodePlex)

Companies have been concerned about software license compliance with respect to free and open source software for some time. Part of this is due to simple competitive FUD designed to frighten people away from using FOSS or to sell services and tools around it, and part of this was due to genuine concern with license compliance when lawsuits appear because of violations. The Linux Foundation announced the Open Compliance Program at LinuxCon in Boston today to help companies understand and manage such compliance needs. I describe and comment on the program on my CodePlex Foundation blog.

Eclipse 2010 Survey Notes Contribution in Open Source Software Projects Declines

I saw from Dana Blankenhorn's blog post the other day that the Eclipse Foundation has once again published its excellent annual survey of Eclipse usage in the world. This is an annual survey that is always interesting because it shows the rise of many free and open source software projects beyond the Eclipse world and their subsequent competition with each other and the traditional products in the marketplace (e.g. Windows, Oracle). There were 1696 completed surveys this year to last year's 1365, i.e. there were almost 25% more respondents this year.

Dana caught sight of a trend noted by Ian Skerrett in his blog post announcing the survey:

Trend #7. Open source participation seems to be stalled. In the survey, we asked a question about the corporate policies towards open source participation. In 2009 48% claimed they could contribute back to OSS but in 2010 only 35.4% claim they could contribute back. Conversely, 41% in 2010 claimed they use open source software but do not contribute back but in 2009 it was 27.1%. Obviously not a trend any open source community would like to see. I am not sure the reason companies would become less restrictive in their open source policies. Any insight or feedback from the community would be appreciated.

The question as asked in the survey reads differently to me: What best describes your organization's policy towards the use of open source software? (Choose one.) Possible answers were:

• Does not allow the use of any open source software (1.4%)
• Uses open source software, but does not interact with open source project communities in any way (35.6%)
• Uses open source software and contributes back (through bug reports, code, resources) to at least one open source project community to help improve the quality of the projects we consume (30.7%)
• Contributes significant development resources (contributors, committers and/or maintainers, project leaders) to at least one open source project community in order to help influence the evolution of the projects we consume (7.7%)
• Has a business model that relies on open source software for its success (11.4%)
• Individual, not affiliated with an organization (9.2%)
• Don't know (4.1%)

There hasn't necessarily been an increase in participants that say they can't contribute, but rather that they don't contribute back. Dana and Ian both ask why this might be the case. Looking to the demographics, there may be a number of reasons.

There's an increase in the percentage of financial services participants over the years (6% to 6.8% to 8.4%). This is a group that has historically been careful in how they contribute and where. The IT crowd is also interesting because using FOSS means that they don't need to figure out how to talk with the accounting department to create a PO for a software trial to solve a problem, but turning it around to the contribution side of the equation, they also don't need to figure out how to find a lawyer to ensure they're giving back in an appropriate manner.

There's an increase in the number of students over the last two reports (8.6% in 2007 down to 8.1% then to 9.8%). This number may be the more interesting set of numbers because the fewer students, the higher the contribution status it seems in the graph (p. 27 in the 2010 report). There are absolutely students that contribute and whose contributions are deeply valued by a number of open source communities, but as a rule, they would be less experience developers and are faced with the learning curves of the project, the technology, and the growth of their own programming skills. This has significance in terms of things that are accepted by the community. They also may simply not know how to contribute as many FOSS repositories do a poor job of delivering the guidance to develop a vibrant community that encourages new developers to join.

All in all, the survey is always a great piece of work and the other trends it finds in it's developer community are always interesting.

Microsoft Failing Its Own OOXML Standard (ISO/IEC 29500)

I was dismayed this morning to see Andy Updegrove's write-up on Alex Brown's post on Microsoft failing it's own Office Open XML (OOXML) standard (formally known as ISO/IEC 29500). It is the second anniversary of the ballot resolution and approval of the standard. While Andy was reporting from the trenches through the final ballot resolution, Alex was responsible for the negotiations that allowed the standard to pass. Essentially Microsoft seems to be breaking the promises it made to the international standards community to get the standard through the process.

If Microsoft ship Office 2010 to handle only the Transitional variant of ISO/IEC 29500 they should expect to be roundly condemned for breaking faith with the International Standards community. This is not the format “approved by ISO/IEC”, it is the format that was rejected.

Unfortunately it's unclear what condemnation will bring. Even were the EU Commission to involve itself as Alex later suggests, it is unlikely that this would effect shareholder value in any meaningful way.

Alex also wonders at how such bad implementation can be allowed to happen:

So why — given the awareness Microsoft has at the top, at the bottom, and round the edges [for standards] — does it still manage to behave as it does? Something, perhaps, is wrong at the centre — some kind of corporate dysfunction caused by a failure of executive oversight.

It's nothing sinister I suspect. Cynically — it was nobody's job, and by that I mean no development manager or program management manager (or test manager for that matter) of any reasonable authority or seniority likely had it as a primary rewardable objective on their annual review. If the bugs were even filed, they were likely never deemed sufficiently important to fix during bug triage on the road to release-to-manufacturing. I saw bug triage meetings circa 1999 on the road to Windows 2000 where non-critical bugs that were effecting 10,000 beta customers were ignored because there were other bugs effecting 100,000 users. When you ship a product that has a consumer base of tens of millions, you learn different skills in the triage process. I suspect it's similar on the Office side of the company.

And Alex is completely correct, there would be no executive oversight pushing down from above on the Office development organization. The vice-president that published the open letter two-years ago making the promises has probably either (a.) moved on to other responsibilities, or (b.) assumed he had made the promise and someone else was to carry it out. It won't be on his review objectives either so he's still being well paid. So too with any other exec in the pipeline two-years ago. Even the standards team that worked so hard to get it through the ECMA and ISO processes will have moved on to other standards (and certainly wouldn't be so naive in the product-centricity of Microsoft to have accepted such an objective so far out of their control). The marketing team got its talking points two years ago. This is a cultural problem. The development teams within the company (i.e. the revenue generation engine) with a few exceptions in a few Web-related product teams just aren't tuned to deal with standards in a serious manner the way certain other vendors do.

Until there are serious lost sales to do with non-conformance from large government organizations, and the field organization starts to seriously yell, there will be no understanding in Redmond that it really mattered and that certain government officials may even have bet their careers on such promises. Even then, the first question in Redmond will [cynically] be, "How much do we sell to the Ministry of [Big Issues] in [Name-of-small-northern-European-country]?"

Alex finishes with the quote:

In short, we find ourselves at a crossroads, and it seems to me that without a change of direction the entire OOXML project is now surely heading for failure.

Failure indeed. I used the photograph at the top of the post two-years ago when I cynically predicted how this was going to go down over time. I summarized my opinions on the battle between ODF and OOXML and how Microsoft should have played the war as one of the examples in a standards primer I wrote around the same time. It will be interesting to watch how Microsoft responds to Alex's post. The world is indeed watching.

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.

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:WAP@CINGULARGPRS.COM
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.