Posts Tagged ‘Free software’
Decoding a .mobileconfig file containing a Cisco IPsec VPN configuration
When someone wants to give you access to a Cisco VPN, they might give you a .mobileconfig file. This is apparently used by MacOS and iOS to encapsulate the configuration parameters needed to connect to a VPN. You should be able to connect to it with open source software (such as NetworkManager and vpnc) as long as you have the right configuration. Some helpful soul has tried to give you that configuration, but it’s wrapped up in an Apple-specific container. Here’s how you rip it open and get the goodies.
File format
A .mobileconfig appears to contain:
- Some binary garbage which is safe to ignore
- An XML document containing the good bits, i.e.:
- The “local identifier” (i.e. IPsec group name)
- The “remote address” (i.e. IPsec gateway host)
- The shared secret (base64 encoded)
- Some more binary garbage which is safe to ignore
…and it looks like this:
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>LocalIdentifier</key>
<string>LOCAL_IDENTIFIER_HERE</string>
<key>LocalIdentifierType</key>
<string>KeyID</string>
<key>RemoteAddress</key>
<string>REMOTE_ADDRESS_HERE</string>
<key>SharedSecret</key>
<data>
BASE64_ENCODED_SHARED_SECRET_HERE
</data>
</dict>
<key>IPv4</key>
<dict>
<key>OverridePrimary</key>
<integer>0</integer>
</dict>
<key>PayloadDescription</key>
<string>...</string>
<key>PayloadDisplayName</key>
<string>...</string>
<key>PayloadIdentifier</key>
<string>...</string>
<key>PayloadOrganization</key>
<string>...</string>
<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>PayloadUUID</key>
<string>...</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>Proxies</key>
<dict>
<key>HTTPEnable</key>
<integer>0</integer>
<key>HTTPSEnable</key>
<integer>0</integer>
<key>ProxyAutoConfigEnable</key>
<integer>0</integer>
<key>ProxyAutoDiscoveryEnable</key>
<integer>0</integer>
</dict>
<key>UserDefinedName</key>
<string>...</string>
<key>VPNType</key>
<string>IPSec</string>
</dict>
</array>
<key>PayloadDescription</key>
<string>...</string>
<key>PayloadDisplayName</key>
<string>...</string>
<key>PayloadIdentifier</key>
<string>...</string>
<key>PayloadOrganization</key>
<string>...</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>...</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
The shared secret is base64-encoded, so you can decode it with:
$ echo -n 'BASE64_ENCODED_SECRET_HERE' | base64 -d
Network Manager configuration
- Make sure you have network-manager-vpnc installed
- Click the Network Manager icon, select “VPN Connections”, “Configure VPN…”
- Create a “Cisco-compatible (vpnc)” connection
Create a “Cisco-compatible (vpnc)” VPN connection
- Configure the connection settings as follows:
Configure the connection settings
- Enter the “remote address” in the “Gateway” field
- Enter the “local identifier” in the “Group name” field
- Enter the shared secret in the “Group password” field
- To connect, click the Network Manager icon, select “VPN Connections”, and select the connection you just configured
Good luck and enjoy!
Building a personal data locker
If you were building a digital container to store your personal data, what would it look like?
Personal data being information associated with you: your contacts, your photos, the web pages you’ve visited, the places you’ve been, the messages you’ve sent and received, and so on. In short, your stuff.
Here’s my personal wish list of technical requirements:
- It has to be made of free software, of course
- It must keep my data secure, while allowing me to share it when and how I want to
- It needs to handle a range of different data types natively, and be extensible to new types, from photos to real-time sensor data
- It should be able to collect my data from many different places where it is being created and stored
- It should have a rich API, so that I can create applications which access my data
- If I want to, I should be able to host it myself, on my own hardware, without compromising my ability to access and share it
Of course, this isn’t merely an academic exercise, as my new day job at Singly is about building exactly this type of system. With a technical team including Jeremie Miller of Jabber and XMPP fame, our goal is to develop a personal data platform which meets these criteria and more.
There’s a lot of work to do, but today, you can check out the code and run a locker of your own, which can sync in data from Facebook, Twitter, Google, Foursquare, Github and dozens of other services. It’s a bit of a bear to set up, particularly if you don’t already have API keys for these services, but that’s fairly normal at this early stage of development.
If you try it, or have thoughts about what we’re doing, please let me know in the comments.
DEX finishes first batch of derivative patches for Debian
It’s been a few months since Zack and I announced the DEX project, which aims to improve the Debian ecosystem by working jointly with derivative distributions.
Our first milestone
The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn’t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old.
I’m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them.
One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project.
This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian.
Conclusions
Although we weren’t quite able to clear the whole list, we still consider the project to be a success because:
- We ensured that all of the patches received due consideration for inclusion in Debian
- We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
- Most importantly, we learned from the experience
What’s next
In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:
- Our second major project, nicknamed “big-merges”, will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
- Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
- Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
- Zack is organizing a derivatives BoF at DebConf 11
We’re looking forward to seeing DEX develop further. If you’d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on freenodeOFTC).
Matt Zimmerman and Stefano Zacchiroli
Why I’m excited about joining Singly
This summer, I’ll be taking a bit of time off, moving back to San Francisco and starting a new job. I can’t wait to get back to work. Here’s why.
Me and my data
I have a singular relationship with my data. I have a copy of every email I’ve sent since I first got an Internet email address in 1994 (82,000 messages and counting). I have even older files downloaded from BBSes, and passed between friends on floppy disks. Chat logs, text messages, voicemail…I hold onto them all. Anything which is relevant to me personally, I tend to save.
This must seem banal to people who are first getting online today. In the age of Gmail and Flickr, it’s easy to assume that all of your data will be preserved indefinitely, with little or no effort on your part. But for me, it has been hard work over the years, because I’ve done it myself. I’ve carried my data with me to countless new computers, operating systems, storage technologies, file formats and cities over the years. Everywhere I’ve lived, I’ve brought it with me. Physically.
Really?
Why do I do this? Why have I gone to such trouble for a collection of bits? Especially now, why is most of my data still at home?
One pragmatic answer is that I can simply do more with my data when I have a copy. I can work with it using any software I want, including software that I write myself. I don’t have to worry about whether I can transfer it from one web service to another. I’m never stuck using yesterday’s services because my data is never trapped in them. My personal data is always available to me me, always raw, ready and waiting for the next wave of software to come along. When it does, I can load my data into it and keep going. The fact that Facebook and Google disagree over sharing their users’ data doesn’t bother me in the least.
Another reason is that I want to be in control of it. I decide who to share my data with, and when. Some of it, I prefer not to share at all, with any person or company, and I have that choice. Even if a powerful government wants to access my data, I am afforded certain protection under the law, at least in the countries where I’ve lived. If I turned over my data to service providers, my choices and protection would likely be much more limited.
I have a deeper emotional attachment to my data as well. Enfolded within that vast pattern of bits is some part of my self. By sharing my personal data with other people, I show them something of who I am. Increasingly, my personal data is part of my identity. This is more than just a state of mind: it’s been shown that even our “non-identifying” personal data can reveal who we are.
In other words, it’s not just “my data”—it’s “me data”.
Singly
I’m joining Singly because I want to take this concept much further, and combine people, data and software into a different shape with people at the center.
Today, we are creating vastly greater amounts of personal data, and it’s stored in many more places. We leave our trail on the Internet in the form of activity streams, messages and content, spread across different web sites, each with their own inscrutable terms of service and (if we’re lucky) their own API. These disconnected silos prevent us from using all of this information effectively.
Meanwhile, we want—and need—to connect with each other in more ways than ever before. We need applications which can connect us, through our personal data, to the services we need.
Singly is building the technology to make this possible. It will be designed with the deepest respect for the relationship that we have with our personal data, and with a vision for truly personal computing.
Singly is…
- A team of passionate people, dedicated to a vision for personal data
- Building an open source data locker, which aggregates and stores your personal data from around the web and ensures that it’s always available to you
- Enabling developers to create powerful distributed applications based on this data, without having to deal with the complexity of multiple web services APIs
- Providing secure hosting services for personal data lockers
- Hiring! We’re looking for people with deep experience in security and cryptography, cloud infrastructure and user experience, as well as software engineering generalists
This opportunity is a great fit for my interests and experience. Singly aims to be the commercial part of a vibrant open source community, and I’m looking forward to building on what I’ve learned in Debian, Canonical and Ubuntu to help make it a success.
I’ll have lots more to say about it as time goes on. Meanwhile, if you’re interested in following what we’re doing, here’s where:
A diversity statement for Ubuntu
The Ubuntu website states that “we aim to make Ubuntu a wonderful place to participate”. We developed the Ubuntu Code of Conduct to set a standard for participants to accept each other in the spirit of cooperation, and have improved it over time to state these principles more clearly.
It is implicit in our philosophy that these and other Ubuntu values should hold equally true for everyone. I would like to propose that we upgrade this to an explicit statement on behalf of the project.
I have spoken with many people who were interested in joining a free software project, but were put off because they felt unwelcome. I know various people who participate in Ubuntu today, but sometimes face difficult social obstacles in order to do so. Going forward, I would like for us, as members of the Ubuntu community, to make the extra effort to accept all kinds of people. This may sound simple, but it can be very difficult to put into practice. People often don’t even notice they’ve gotten it wrong, until the offended party points it out to them. We need tools and guidance to make this a reality.
To that end, I would like to propose a diversity statement for Ubuntu. This draft has already received support from a majority of the Community Council, but I’d like to take it a step further. Because I want this to be a commitment that we can all stand behind, I’m also calling for support from the community as a whole. Please give this issue your consideration, and let me know in the comments if you can get on board with an official statement like this. The more support we have, the more real this commitment can be.
Here’s the text. Many thanks to Mary Gardiner, Valerie Aurora and Benjamin Mako Hill for their review and input.
The Ubuntu project welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining. Although we may not be able to satisfy everyone, we will always work to treat everyone well.
Standards for behavior in the Ubuntu community are detailed in the Code of Conduct and Leadership Code of Conduct. We expect participants in our community to meet these standards in all their interactions and to help others to do so as well.
Whenever any participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong.
Although this list cannot be exhaustive, we explicitly honor diversity in age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socio-economic status, subculture, and technical ability.
Some of the ideas and wording for this statement were based on diversity statements from the Python community and Dreamwidth Studios (CC-BY-SA 3.0).
Rejoining Debian
A couple of months ago, Debian project membership voted, after extensive discussion, to implement a fundamental change in the Debian community: to welcome as members people who make a valuable contribution to the project, even if they are contributing something other than source code.
This was a tremendous milestone for Debian, and one which made me feel proud to have been a part of the project. Historically, only developers had been eligible for membership, including voting and other formal privileges. Although other kinds of contributions were welcome, this disparity gave the impression that they were less valued than code contributions. It seemed to me at the time that Debian’s mission was to package all of the free software in the world, and if one’s efforts didn’t go directly to improving packages, they just weren’t as important.
I don’t remember when I first installed Debian, but I made my first contributions to the project in 1999, and officially joined as a developer in 2000. After several fun and rewarding years of packaging and development, I started a very demanding day job, and spent more and more of my energy into that, and less and less coding for Debian as a volunteer. However, my job with Canonical involved working with Debian, and that was a primary reason why it was interesting to me. It was an opportunity to introduce a whole new population of people to the things I loved about Debian.
The reality, of course, was more complicated. Following the launch in 2004, Ubuntu grew quickly in popularity and scope, diverged from Debian in significant ways, and relations between Debian and Ubuntu became strained. Canonical grew quickly as well, and the combination of a growing community, a growing company and growing user adoption was a challenge for everyone concerned. As a Canonical manager and a Debian developer, I felt the strain as much as anyone.
Meanwhile, and I felt more and more alienated from Debian. Debian developers who had been friendly in the past became suspicious of Ubuntu—and me—and I quickly became an outsider. My code contributions to Debian continued to decline, and I was no longer maintaining any packages. In Debian at the time, that meant that I didn’t exist. I saw it as an important part of my job to work with my counterparts in Debian, in a coordinating role, but found this increasingly impractical. In 2007, I received an inquiry from the Debian Account Manager, who had noticed I wasn’t actively involved in packaging, and wished to disable my account for security reasons if I wasn’t using it. Although I wanted to remain active in the Debian community, I had to agree that it wasn’t good security practice for me to hold onto my developer privileges. I relinquished my upload rights, with the option to come back if I resumed my development work, and officially became a nobody: I lost the right to vote, my email address and mailing list subscriptions, and all other official ties with Debian, except for the record of my GPG key in a special “emeritus” keyring for informational purposes.
Last month, Enrico Zini announced instructions for contributors to apply for membership under the new guidelines, which recognize many kinds of contributions, not only code. Today, after a three year hiatus, I am proud to be the first Debian member to be accepted through this new process. I expect to continue to submit the occasional patch, but my primary interest is in healing the rift which still exists between Debian and Ubuntu by contributing in a more personal way. Please feel free to contact me if you’d like to work together on this. You can reach me as mdz at either debian.org or ubuntu.com, or on IRC.
I would like to thank Stefano Zacchiroli, for proposing the General Resolution which enabled Debian to make this transition, and for all of his other work as Debian Project Leader to help Debian grow and improve. I also appreciate Enrico Zini, Jonathan McDowell and Martin Zobel-Helas for expediently processing me and working through the technical changes needed to implement the resolution correctly.
It’s good to be back.
Ubuntu Brainstorm Top 10 for December 2010
As I mentioned recently, the Ubuntu Technical Board is reviewing the most popular topics in Ubuntu Brainstorm and coordinating official responses on behalf of the project. This means that the most popular topics on Ubuntu Brainstorm receive expert answers from the people working in these areas.
This is the first batch, and we plan to repeat this process each quarter. We’ll use feedback and experiences from this run to improve it for next time, so let us know what you think.
Power management (idea #24782)
Laptops are now outselling desktops globally, and laptop owners want to get the most out of their expensive and heavy batteries. So it’s no surprise that people are wondering about improved power management in Ubuntu. This is a complex topic which spans the Linux software stack, and certainly isn’t an issue which will be “solved” in the foreseeable future, but we see a lot of good work being done in this area.
To tell us about it, Amit Kucheria, Ubuntu kernel developer and leader of the Linaro working group on Power Management, contributed a great writeup on this topic, with technical analysis, tips and recommendations, and a look at what’s coming next.
I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not require the user to make several (difficult) choices. It should just work – providing a good balance of performance and battery life.
IP address conflicts (idea #25648)
IP addressing is a subject that most people should never have to think about. When something isn’t working, and two computers end up with the same IP address, it can be hard to tell what’s wrong. I was personally surprised to find this one near the top of the list on Ubuntu Brainstorm, since it seems unlikely to be a very common problem. Nonetheless, it was voted up, and we’re listening.
There is a tool called ipwatchd which is already available in the package repository, and was created specifically to address this problem. This seems like a further indication that this problem may be more widespread than I might assume.
The idea has already been marked as “implemented” in Brainstorm based on the existence of this package, but that doesn’t help people who have never heard of ipwatchd, much less found and installed it.
What do you think? Have you ever run into this problem? Would it have helped you if your computer had told you what was wrong, or would it have only confused you further? Is it worth considering this for inclusion in the default install? Post your comments in Brainstorm.
Selecting the only available username to login (idea #6974)
Although Linux is designed as a multi-user operating system, most Ubuntu systems are only used by one person. In that light, it seems a bit redundant to ask the user to identify themselves every time they login, by clicking on their username. Why not just preselect it? Indeed, this would be relatively simple to implement, but the real question is whether it is the right choice for users.
Martin Pitt of the Ubuntu Desktop Team notes that consistency is an important factor in ease of use, and asks for further feedback.
So in summary, we favored consistency and predictablility over the extra effort to press Enter once. This hasn’t been a very strong opinion or decision, though, and the desktop team would be happy to revise it.
Icon for .deb packages (idea #25197)
Building on the invaluable efforts of Debian developers, we work hard to make sure that people can get all of the software they need from Ubuntu repositories through Software Center and APT, where they are authenticated and secure. However, in practice, it is occasionally necessary for users to work with .deb files directly.
Brainstorm idea 25197 suggests that the icon used to represent .deb packages in the file manager is not ideal, and can be confusing.
Matthew Paul Thomas of the Canonical Design Team responds with encouragement for deb-thumbnailer, which makes the icon both more distinctive and more informative. He has opened bug 685851 to track progress on getting it packaged and into the main repository.
I have reviewed the proposed solutions with Michael Vogt, our packaging expert. Solution #1 is straightforward, but we particularly like solutions #5 and #10, using a thumbnailer to show the application icon from inside each package.
Keeping the time accurate over the Internet by default (idea #25301)
It’s important for an Internet connected computer to know the correct time of day, which is why Ubuntu has included automatic Internet time synchronization with NTP since the very first release (4.10 “warty”). So some of us were a little surprised to see this as one of the most popular ideas on Ubuntu Brainstorm.
Colin Watson of the Ubuntu Technical Board investigated and discovered a case where this wasn’t working correctly. It’s now fixed for Ubuntu 11.04, and Colin has sent the patches upstream to Debian and GNOME.
My first reaction was “hey, that’s odd – I thought we already did that?”. We install the ntpdate package by default (although it’s deprecated upstream in favour of other tools, but that shouldn’t be important here). ntpdate is run from /etc/network/if-up.d/ntpdate, in other words every time you connect to a network, which should be acceptably frequent for most people, so it really ought to Just Work by default. But this is one of the top ten problems where users have gone to the trouble of proposing solutions on Brainstorm, so it couldn’t be that simple. What was going on?
More detail in GNOME system monitor (idea #25887)
Under System, Preferences, System Monitor, you can find a tool to peek “under the hood” at the Linux processes which power every Ubuntu system. Power users, hungry for more detail on their systems’ inner workings, voted to suggest that more detail be made available through this interface.
Robert Ancell of the Ubuntu Desktop Team answered their call by offering to mentor a volunteer to develop a patch, and someone has already stepped up with a first draft.
Help the user understand when closing a window does not close the app (idea #25801)
When the user clicks the close button, most applications obediently exit. A few, though, will just hide, and continue running, because they assume that’s what the user actually wants, and it can be hard to tell which has happened.
Ivanka Majic, Creative Strategy Lead at Canonical, shares her perspective on this issue, with a pointer to work in progress to resolve it.
This is more than a good idea, it’s an important gap in the usability of most of the desktop operating systems in widespread use today.
Ubuntu Software Centre Removal of Configuration Files (idea #24963)
One feature of the Debian packaging system used in Ubuntu is that it draws a distinction between “removing” a package and “purging” it. Purging should remove all traces of the package, such that installing and then immediately purging a package should return the system to the same state. Removing will leave certain files behind, including system configuration files and sometimes runtime data.
This subtle distinction is useful to system administrators, but only serves to confuse most end users, so it’s not exposed by Software Center: it just defaults to “removing” packages. This proposal in Ubuntu Brainstorm suggests that Software Center should purge packages by default instead.
Michael Vogt of the Ubuntu Foundations Team explains the reasoning behind this default, and offers an alternative suggestion based on his experience with the package management system.
This is not a easy problem and we need to carefully balance the needs to keep the UI simple with the needs to keep the system from accumulating cruft.
Ubuntu One file sync progress (idea #25417)
Ubuntu One file synchronization works behind the scenes, uploading and downloading as needed to replicate your data to multiple computers. It does most of its work silently, and it can be hard to tell what it is doing or when it will be finished.
John Lenton, engineering manager for the Ubuntu One Desktop+ team, posts on the AskUbuntu Q&A site with tools and tips which work today, and their plans to address this issue comprehensively in the future.
Multimedia performance (idea #24878)
With a cornucopia of multimedia content available online today, it’s important that users be able to access it quickly and easily. Poor performance in the audio, video and graphics subsystems can spoil the experience, if resource-hungry multimedia applications can’t keep up with the flow of data.
Allison Randal, Ubuntu Technical Architect, answers with an analysis of the problem and the proposed solutions, an overview of current activity in this area, and pointers for getting involved.
The fundamental concern is a classic one for large systems: changes in one part of the system affect the performance of another part of the system. It’s modestly difficult to measure the performance effects of local changes, but exponentially more difficult to measure the “network effects” of changes across the system.
Three ways for Ubuntu to help developers
Developers are a crucial part of any successful software platform. In the same way that an operating system is “just” a means for people to use applications, a platform is “just” a means for developers to create applications and make them available to people.
There are three primary ways in which Ubuntu can help developers do their work. They are all related, but distinct, and so we should consider them individually:
1. Developing for Ubuntu
Today, Ubuntu bundles thousands of free software applications, for both clients and servers, most of which are packaged by Debian.
Ubuntu also carries certifications for a variety of third-party ISV software, both open source and proprietary, which are coordinated through Canonical’s partner program.
In both of these cases, many of these applications are actually developed on other platforms, and ported to Ubuntu, either by the free software community or by the creators of the software.
2. Developing on Ubuntu
Ubuntu is already quite popular among developers, who mainly run Desktop Edition on their workstations. They might be developing:
- web applications (with server-side and browser components)
- portable applications (e.g. using Java, or Adobe AIR)
- mobile applications (e.g. for Android or iOS)
- native applications, which might target Ubuntu Desktop Edition itself, or supporting multiple platforms through a framework like Qt
3. Distributing through Ubuntu
Like other modern operating systems, Ubuntu isn’t just a platform where applications run, but also a system for finding and installing applications. Starting with APT, which originated in Debian, we’ve added Software Center, the ISV partner repository, and various other capabilities in this area. They all help to connect developers with users, facilitating distribution of software to users, and feedback to developers.
So, where should we focus?
Some developers might be interested in all three of these, while others might only care about one or two.
However, most of the developer improvements we could make in Ubuntu would only address one of these areas.
For this reason, I think it’s important that we consider the question of the relative importance of these three developer scenarios. Given that we want Ubuntu to flourish as a platform, how would we prioritize them?
I have my own ideas, which I’ll write about in subsequent posts, but here’s your chance to tell me what you think. :-)
Ubuntu: Project, Platform, Products
When most people talk about Ubuntu, they usually mean our flagship product, Ubuntu Desktop Edition. Sometimes, they might mean the Ubuntu project, or the community of people who work on it, or various other things.
Similarly, Debian might mean the Debian operating system, or the package repositories, or the project, and so on.
This gets a little confusing sometimes. When I’m talking about Ubuntu, I’ve started to use more specific terminology to explain what I mean, and this seems to help people understand better the nature of the whole Ubuntu. In particular, I use the three Ps:
- a portfolio of products, including Desktop Edition, Server Edition, Netbook Edition, Kubuntu and more. These are software bundles which can be downloaded, pre-installed on retail computers, and so on. Each one is designed to meet a certain set of user needs, and to work on a specific form factor of computer.
- a technology platform, which can be used to build a wide range of products. It is primarily of interest to developers, who build derivative distributions, OS products, applications and infrastructure using Ubuntu packages. This platform is the common foundation of the Ubuntu products above, and includes things like the global package repository. Joel Spolsky does a good job of explaining why platforms are distinctly different from products, and should be treated as such.
- an open community project, which collectively produces, distributes, promotes and supports the products and the platform. The Ubuntu project has a philosophy, a government, and various tools and processes to help contributors work together. Canonical supports the Ubuntu project by providing resources and infrastructure, and also directly participates in Ubuntu at various levels.
This breakdown may seem a bit obvious to those of us “on the inside”, but it’s confusing to people who are encountering it for the first time. I’m sharing this in the hope that if more people start using the same words, it will get easier for people to understand how these pieces fit together. I’ll also be linking to it a lot, to help put things into context using this framework.
Back to the future
In my professional role as Ubuntu CTO, I take on a number of different perspectives, which sometimes compete for my attention, including:
- Inward – supporting the people in my department, alignment with other departments in Canonical and reporting upward
- Outward – connecting with customers, partners and the free software community, including Debian
- Forward – considering the future of the Ubuntu platform and products, based on the needs of their users, our customers and business stakeholders within Canonical
- Outside-in – taking off my Canonical hat and putting on an Ubuntu hat, and looking at what we’re doing from an outside perspective
My recent work, as Canonical has gone through a period of organizational growth and change, has prioritized the inward perspective. I took on a six-month project which was inwardly focused, temporarily handing off many of my day-to-day responsibilities (well done, Robbie!). I’ve grappled with an assortment of growing pains as many new people joined Canonical over the past year.
With that work behind me, it’s time to rebalance myself and focus more outside of Canonical again. It’s good to be back!
In my outward facing capacity, I’ll shortly be attending Web 2.0 Summit in San Francisco. I attend several free software conferences each year, but this is a different crowd. I hope to renew some old ties, form some new ones, and generally derive inspiration from the people and organizations represented there. Being in the San Francisco Bay area will also give me an opportunity to meet with some of Canonical’s partners there, as well as friends and acquaintances from the free software community. With my head down, working hard to make things happen, it’s easy to lose perspective on how that work fits into the outside world. Spending more time with people outside of Canonical and Ubuntu is an important way of balancing that effect.
Looking forward, I’ll be thinking about the longer term direction for the Ubuntu platform. The platform is the layer of Ubuntu which makes everything else possible: it’s how we weave together products like Desktop Edition and Server Edition, and it’s what developers target when they write applications. Behind the user interfaces and applications, there is a rich platform of tools and services which link it all together. It’s in this aspect of Ubuntu that I’ll be investing my time in research, experimentation and imagination. This includes considering how we package and distribute software, how we adapt to technological shifts, and highlighting opportunities to cooperate with other open source projects.
My primary outside-in role is as chair of the Ubuntu Technical Board. In this capacity, I’m accountable to the Ubuntu project, the interests of its members, and the people who use the software we provide. Originally, the TB was closely involved with a range of front-line technical decisions in Ubuntu, but today, there are strong, autonomous teams in place for the most active parts of the project, so we only get involved when there is a problem, or if a technical question comes up which doesn’t “fit” the charter of an established team. It’s something of a catch-all. I’d like to re-establish the TB in a more central role in Ubuntu, looking after concerns which affect the project as a whole, such as transparency and development processes. I’m also re-joining Debian as a non-uploading contributor, to work on stimulating and coordinating cooperation between Debian and Ubuntu. I’m looking forward to working more with Zack on joint projects in this area.
This change will help me to support Canonical and Ubuntu more effectively as they continue to grow and change. I look forward to exercising some mental muscles I haven’t used very much lately, and facing some new challenges as well.
We'll see | Matt Zimmerman 
