Capabilities for Open Source Innovation: Background

Over the past decade, I’ve been researching open source and technology innovation, partly through employment at multiple different companies who engage in open source, and partly through academic work towards completing a Master’s degree and soon starting a PhD. The heart of this research is looking into what makes companies successful at open source and also at technology innovation. It turns out there are actually many things in common between the two.

Organizational Capabilities

One of the lines of research that’s relevant to this topic explores organizational capabilities. These capabilities are the knowledge that individuals have at a company, but they’re also the abilities the company as a whole has built into their processes, into their business, and into their employees. Capabilities can be learned over time, so a company isn’t frozen to a fixed point of capabilities that can never change, but it does take time to build up new capabilities or strengthen existing capabilities. If a company doesn’t have the capabilities to tackle a totally new strategic area or a totally new project, then deciding to enter that new area is only the first step of a learning process. Organizational capabilities also affect strategic outcomes, so if two companies make the same strategic business decision—no matter how good that decision is in the context of their target market—one company may succeed because it has the organizational capabilities required to achieve that strategic goal, while the other company fails because it is lacking necessary capabilities.

Open Innovation

Another relevant line of research explores open innovation, which was first proposed by Henry Chesbrough in the 2000s, but has been through a number of different iterations over the decade plus since then. In some ways, open innovation is similar to open source, but it’s not quite open source and people get confused about that. The fundamental concept of open innovation is that innovation in general—and this can be technology innovation or business innovation—can be accelerated if companies are willing to go outside their boundaries and either share innovative ideas externally or assimilate external innovative ideas internally. An idea that a company shares outward may be one that they can’t profit from directly, but the other company can help them profit from it, so together they can both make more profit than if the idea just died internally. Being open to assimilate ideas that other companies created means having capabilities (processes and knowledge) around taking that innovation from outside and building it into your own innovation internally.

Open innovation is related to open source in the sense that open source does include both concepts of sharing your internal innovation externally and bringing external innovation internally. But it goes beyond just sharing ideas and knowledge, to actually sharing source code externally and bringing external source code inside the company. If your company is successful at open innovation, you have a set of capabilities towards being successful at open source. You’re not all the way there, but it’s a good boost to getting there.

Much of the change a company makes to become capable in open source has to do with thinking slightly differently about how you create and capture value for customers. It’s no longer a matter of creating all value yourself and capturing all value yourself. Perhaps you created some code, someone else created some more code, and yet another someone created even more code, and you’re getting much more value out of the code that you all develop together than you’re putting into it. Which means you can actually be more effective at driving innovation by not doing all the work yourself. A big part of the change is a matter of getting comfortable doing development in a way that is not purely under your direction. Work isn’t driven under one company from someone up on high, down through a hierarchy, to a set of individual developers. Instead, the work involves relationships across company boundaries.

Levels of Engagement

There are different kinds of relationships across company boundaries. Some relevant research into these relationships is around companies’ levels of engagement in open source and how that impacts their success, their failure, the capabilities they need to succeed, and ultimately their effectiveness in open source and in delivering value to their customers from open source.

Level 1: The lowest degree of engagement is often called Inner Source. A company at this level has taken some ideas from open source, but isn’t consuming external code or sharing code externally, they are just collaborating internally a little more like an open source project.

Level 2: The next step up is to use open source, but purely as a consumer, bringing in external code.

Level 3: Companies at this level deliver open source to customers, either straight up, combined with other open source software, or combined with proprietary software.

Level 4: Companies at this level lead an open source project that they created. They release their code as open source, but they don’t really have an active external community.

Level 5: Companies at this level participate in external projects by contributing code, sponsoring, or supporting the project in other ways, but the relationship is somewhat one-directional or distant. Their participation isn’t highly active, but they still benefit from contributing patches and other support, and getting back the source code.

Level 6: The highest degree of effective open source participation is companies who participate as co-leaders. These companies don’t just throw patches over the wall at the open source project, but take the time to actively share their needs with the open source project, to actively advocate for the directions that they think the project needs to go, and contribute developer time to the project. That doesn’t mean they control the project, in fact, there’s a great deal of value in having many perspectives contributing ideas and together negotiating the direction of the project, for the benefit of everyone involved. At this level, you find companies participating as equals with individual open source developers and respecting them for their technical expertise and role in the project. There’s some nuance here, in terms of how to be effective as a co-leader in an open source project, but the biggest thing to understand is that companies who take that step forward are more effective and get more value out of open source projects.

Other Relationships Across Company Boundaries

Some other relevant research is around more traditional collaborative innovation approaches like strategic alliances, where companies get together under a strong NDA and binding contracts to do some development. These kinds of alliances generally produce proprietary software rather than open source, but some of the research around how strategic alliances work and how companies participate in them is similar to the way companies participate in open source, so the research is relevant.

Research into standards bodies with patent pools is also relevant. The patent pools give the participating companies some degree of protection from each other, which makes them more comfortable all sharing together in terms of the strategic direction and the advancement of the technology. Open source foundations often play a similar role when they include some aspects of patent calming within their contribution and licensing terms, so the participating companies don’t have to be afraid of each other. They can set aside defensive tactics and focus on what’s best for the technology, what’s best for innovation, and what’s going to give all the companies the best value together.

Internal and outsourced R&D also have many similarities to open source. The way an internal R&D department works, or the way a company relates to an outsourcing partner, are in fact very similar to the way that a company relates to an open source project, or the way that companies relate to each other within an open source project. Both open source and more traditional R&D approaches are examples of development happening in a different group, and they require building the same kinds of relationships across the different groups.

Another relevant piece of research is licensing as acquisition. Licensing technology or components as part of a larger effort in innovation is an incredibly common pattern. When one company needs an innovative technology that another company has already developed, they negotiate a license with the other company to use that technology rather than spending the time and money to develop it in-house. The difference between this form of proprietary licensing and open source licensing, is that open source makes the whole process of licensing external innovative technology much easier, because you don’t have a long negotiation before you get to the point that you can license that technology. Open source technology is just freely available under the open source license, you can pick it up, try it, and choose whether you want to integrate it or not. This is one of the concrete ways that open source accelerates innovation, because it makes it faster and easier for companies to acquire innovative technologies and components through licensing.

Technology Innovation and Open Source

The overall focus of this background study was looking at existing research into technology innovation and existing research into open source, and exploring the similarities between the two sets of research. I didn’t start off with specific assumptions on what I might find, just an idea of cross-referencing between the two, since the people who research the two topics don’t seem to talk to each other, read each other’s research, or attend the same conferences. What I found is that the organizational capabilities required to succeed at technology innovation are a very near match to the organizational capabilities required to succeed at open source. I mapped out more than 100 shared characteristics, but I’ll summarize the top few.

Collaborate with external communities: You will innovate faster by taking advantage of available knowledge and resources out in the open, than by trying to do it all yourself internally. Source code is one form of external knowledge and resources that you can use to help your company innovate faster.

Share ideas outward: Tightly grasping every idea you have internally is generally not the path of greatest advantage. You can help accelerate the entire pool of innovation if you’re willing to share ideas outward, and see if other people are willing to contribute to successfully implementing those ideas.

Organizational learning, assimilate ideas inward: Observing external technology innovation or open source isn’t enough, you have to have capabilities in place to assimilate external knowledge and external code.

Efficiency of reuse/modification: In both open source and more general technology innovation, you get an acceleration of innovation from the reuse or modification of existing innovation. There are slightly different mechanics around that in proprietary technology innovation and open source, but the organizational capabilities are basically the same.

Strategic approach to customer value: One set of authors (Morgan & Finnegan) called this “strategic open source”. It’s about taking an approach to customer value where you’re not just blindly assuming that the only way to produce customer value is to do everything yourself in-house, but instead consciously examining your customers’ needs, the capabilities you have, the technology you have, and strategically planning out which pieces you should outsource, which pieces you should build in-house, and which pieces would benefit from inviting customers to participate in creating that value, because it will serve their needs better if they’re involved.

Low barrier to entry: In open source this is partly related to the licensing, which makes it easy to pick up the source code and use it. More generally, it has to do with the fact that innovation moves faster as a whole, across an industry, when we aren’t working in tightly constrained silos. If every company across the cloud industry was working in a silo, we would pretty much have Amazon leading the pack, a couple of other companies struggling to try to do something similar, and that’s it. The barrier to entry for any one company entering the industry would be far too high. When a number of companies are willing to share their ideas and work together, the combined brain power of all of those companies together is orders of magnitude larger than any one company on its own.

Conclusion

If you only take away one thing from this post, make it this: open source is mostly just technology innovation. If your company has already developed the capabilities for technology innovation, then open source won’t be a big hurdle. There are a few new things to learn, but it’s not as radically different as you might think. If your company hasn’t really embraced technology innovation yet, you’ll find open source and any other approach to technology innovation challenging. The good news is, the capabilities that you need to learn to effectively engage with open source, are actually pretty much the same capabilities you need to learn to effectively innovate at technology anyway. And, open source is a particularly easy way to learn those capabilities, because open source communities are generally eager to teach people how to participate and how to succeed with their project. Your competitors in proprietary technology innovation, on the other hand, probably consider every aspect of their technology a closely guarded secret, and are unlikely to have any interest in sharing or helping you learn from their successes and mistakes.

Relativity, skepticism, and virtual worlds

Yesterday on Twitter I posted:

Has anyone applied Einstein’s theory of relativity to radical skepticism? i.e. spaces of reference in knowledge relative to each other.

Twitter is great for tossing out a quick idea, but on reflection, this one probably needs more explanation. To give credit where credit is due, the idea occurred to me while I was watching a Coursera lecture on Epistemology by Duncan Pritchard (University of Edinburgh) for an evening’s entertainment (what can I say, it’s more fun than most things on television). Though, ultimately, the idea is a distillation of several lines of thought that have been knocking around in my head for years now. (If you really, really want to get at the roots, it all goes back to Richard Jozsa, who was my professor in Quantum Computation at the University of Bristol before he moved on to Cambridge, and who set me on a whole new path of thinking.)

First, a bit of lightweight background, so everyone can follow along. In very rough terms, radical skepticism is a perspective on the fundamental nature of human knowledge, specifically that knowledge is impossible. Pritchard used the classic “brain in a vat” or “Matrix” illustration, which might be simply stated: If I were a brain in a vat, being fed fake experiences by a computer (far more advanced than any we currently have, but still, play along for the sake of argument), then everything I think I know about the universe would actually be fake. I wouldn’t really “know” anything. And the kicker is, there really isn’t any way to prove I’m not a brain in a vat, and therefore, at a very basic level there isn’t any way to prove that anything I know is true. (Apologies to academic philosophers who might happen to read this, I’m keeping the explanation as simple as possible.)

Now, relativity in physics (again, very much simplified) is a theory that examines motion within frames of reference. For an intuitive sense of what this means, go outside and throw a ball to a friend so they can catch it. Now, go ride on a train with the friend and throw a ball there (try not to hit the other passengers). The two situations have radically different external contexts, one is stationary on the sidewalk, the other is hurtling along the tracks. And yet, for you, the friend, and the ball, the motion is the same: if you throw the same way and catch the same way, the arc of the ball relative to the two of you would be the same. The train car forms a frame of reference, and you can meaningfully examine the laws of physics within that frame, while completely ignoring the motion outside the frame. And, of course, remember that even the “stationary” case is actually on a planet that’s spinning and hurtling through space around the sun, in a universe that’s also in constant motion.

(Digression: Years ago, I set out on a lark to memorise the entirety of an English translation of Einstein’s “Spezielle Relativitätstheorie” i.e. “The Theory of Special Relativity” (Doc. 71, Princeton Lectures). I still can’t recite the whole thing verbatim, but a funny thing happened along the way (as I took classes in quantum mechanics and astrophysics): at one point a lightbulb went off and I suddenly realized I wasn’t just memorizing anymore, I was beginning to understand what Einstein was talking about on a deep level.)

Okay, bringing it back around, the problem with radical skepticism is that if you declare that it’s impossible to know anything, then any study of the fundamental nature of human knowledge, philosophy, or ultimately our entire existence, is really rather meaningless. Simply saying “it doesn’t really matter if I’m a brain in a vat” is a shatteringly weak argument in the face of “everything you think you know is wrong”. And yet, the recorded history of humanity demonstrates that it’s possible to construct internally consistent systems of knowledge, and value in exploring the nature of that knowledge. What if, instead of trying to wave away radical skepticism in a puff of smoke, we instead accepted it as a fundamental truth, at the same time as systematizing a study of knowledge within frames of reference, analogous to Cartesian frames of geometry or relativity frames of motion. So, whether I am a brain in a vat, or a living, breathing physical organism experiencing a physical environment, I exist within a “frame of reference” (a computer-constructed or physical world). Within that frame it’s meaningful to study the system of knowledge, while abstracting away from details outside the frame. It’s even meaningful to study the nature of knowledge across different frames of reference, for example as either a brain in a vat or a physical organism I might “know” that I have two hands, that one of them is grasping a cup of coffee, etc, etc. In either frame, I have a true belief, reached through the reasonable application of my cognitive abilities. My knowledge of my hand and my knowledge of the coffee cup are the same relative to each other, within both frames of reference. In a sense, we can say that the “laws of knowledge” are consistent across frames of reference.

Let’s take it one step further. When I inhabit a virtual world, whether it’s as vast and mutable as Minecraft, or as carefully controlled as a game in the Zelda series, I enter into a frame of reference of knowledge. I become a “brain in a vat” to that virtual world, because my dual existence as a physical organism in a physical world isn’t relevant within that frame. This is only becoming more true as technologies like Emotiv’s EPOC controller begin to make the brain-to-world connection more direct, and technologies like Oculus Rift begin to make the world-to-brain connection more direct. Within the frame of reference of a virtual world, I may have genuine knowledge that I have two hands, and that one of them is holding an object. As a slightly more abstract but still narrow example, I may have knowledge of completely different physical laws in two frames of reference (one may not have gravity, or may permit me to fall from 1,000 feet without injury), and yet both have an internally consistent set of physical laws, and my knowledge of those physical laws is absolutely essential to my ability to function as an entity within that frame of reference. And, I can meaningfully compare the nature of my knowledge of physical laws across the two frames of reference, even though the physical laws themselves are different. So frames of reference in knowledge aren’t merely an academic abstraction for the sake of reconciling two apparently conflicting approaches to philosophy. They’re also potentially a valuable tool in the study of the fundamental nature of human knowledge, in much the same way that relativity was to physics.

BTW, if anyone knows of research or published articles heading in this general direction of thought, I’d be very interested to hear/read more about it.

Open Source Enlightenment

(My thanks to Audrey Tang for this lyrical transcript of my talk at OSDC.tw, to Macpaul Lin for the video, and to Chia-liang Kao for proofreading the Chinese translations in my slides.)

Over the years, I’ve started thinking that participating in the open source community is like traveling on a path, toward becoming not only better programmers, but also becoming better people by working together.

You might think of it as a path toward enlightenment, growing ourselves as human beings. So what follows is really my personal philosophy which I’d like to share with you.

The first thing is this: The most important part of every open source project is the people. While code is important, the center is always the people.

There are different kinds of people involved in a project: People who code, who write documentation, who write tests. People who use your software, too, are just as important for a project.

Also there are people who work on the software that your project uses — you’re likely using projects from other people in the upstream, and you might want to send them a patch from time to time.

Or maybe you’re writing a library or a module, and so other people will be using your software, and communicating with you as their upstream as well.

So why do people work on open source software? This is a very important question to ask, in order to understand how open source works.

For people’s day jobs, they may be working with software already. And why would they take the extra effort to work on open source? Part of it is that it involves working on exciting things and new technologies.

Sharing is also a large part of it; as we share with each other, we increase the amount of fun for everyone working together on an open source project.

People also work on open source in a spirit of giving to others; in doing that we’re reaching out as human beings, and this is a very important part of being human.

There are many rewards, too. A big one is respect: As we create something new, draw people in, and share software with them that they can work on too, they recognize who you are and what you are capable of, which gives you a sense of accomplishment.

Conversely, it means that we want to make sure that we show respect to people joining our projects in any way we can, because it helps them to stay involved.

Another important aspect is appreciation; as people publish their work, if you talk with them — Even just a simple thank-you email message saying “this meant a lot of me”, it helps bring about a culture that keeps everybody motivated.

Credit is also important. As you are presenting a project, be sure to mention other people around you, saying “this person did such a wonderful thing”, so we can build a feeling of community together.

One of the things that keeps people interested in open source is that, as we work together, we become stronger and can do more.

Part of it is simple math: 2x people makes at least 2x code, and 3x people makes 3x code, although there is much more to it than that.

When we work together, we can make each other stronger and better — part of that is encouraging each other; as you see people working on a very difficult problem, you can encourage them saying “you are doing great, and I see you will do great in the future”.

You can empower people just by talking and sharing with them.

And then also there’s the fact that, when you have many people together, they’ll have different sets of skills. When you are working together, maybe you know the five things the project needs, and they know the other five things, and so you have the complete set of skills to finish the project, which wouldn’t be possible if either of you worked alone.

So the effect is not only a linear increase in productivity; there’s a multiplication effect when people start working together.

Encouraging each other to look beyond, to look into the future, is also important — We can all inspire others to solve interesting problems. Sometimes just saying “I have an idea” is enough for someone else to make it into reality.

Sometimes you’d look at what someone else is doing — you have not done all the work, but you have the critical idea they needed, and so with that idea they can reach out and go much further.

The key thing about working on open source is that we’re not just standing alone. When you are working with other people, the main thing you’d want to improve is your communication skills.

We communicate about the plans we have: How we want to make the software, personal plans such as a feature you want to work on, and so on.

One of the things I observed in open source communities is this: People often have good plans to create software, but they sometimes clash and fail to communicate with each other about plans. If you work on one plan alone, without communication, you may end up hurting people working on other plans.

So it’s like a hive of bees — a constant buzz keeps us all functioning.

We’ll also often communicate about possible futures: What’s the best way to solve a technical problem? When this happens, you may communicate in a way that’s contentious and angry, making it very hard to make actual progress.

One of the things we’re learning in our process is how to embrace all possibilities. Keep working on the possibility you’ve imagined, but remain fully open to other possibilities other people may have.

And as you make progress, you’ll also be communicating constantly about what you have done — There’s email, there’s twitter… there are many ways to let people know about your progress.

Sometimes we may feel shy, or not wanting to be seen as bragging. But that’s not what it is! It’s good for the project, and for the people as well, because they can learn from what you have done.

Another aspect of communication skills is the ability to ask questions. The advantage of having a community is that some people might have solved your problem before, and asking a question on a forum or IRC may save you days of work.

In the same way, when others are learning, you can be responsive to them too, instead of putting them down like answering with “RTFM” for simple questions.

It’s true that answering “RTFM” maybe save you a bit of time, but it is also teaching that person that they shouldn’t ask those questions in the first place. That is not what you want to teach people at all — you want to teach them to communicate with others.

Also, learn how to make answers that are helpful to people, and help them see that they can also walk down the path as well, and take the path further in the future.

Sometimes you do have to criticize people; we should be open to many ways of doing things, but sometimes one technical solution really is more correct than others. However, the best way to get people to change their ways is to answer them kindly, so they can be open to learning from you.

You have to show some grace, even to people who do not respond very well. Some people may be harsh with you, but this is also part of the path. Sometimes it helps to have a thicker skin, and even in situations when other people should have said things nicer and better, maybe there’s a bit of truth in what they are saying, and you can still learn from that.

From this perspective, even if they speak in a way that is not polite, you can still respond politely.

The other half of communication is not talking, but listening. Instead of telling others what we think, sometimes all that’s needed is just sitting very quietly, and let others talk.

It’s not just listening, though — it’s important to have empathy. As the saying goes, “If you really want to understand someone, you have to walk a mile in their shoes” — perhaps so you can get the blisters they have experienced.

Now, some people think you have to be a genius to work on open source software, but that is simply not true. There are people like Larry and Guido and Linus, yes, but there are also so many different kinds of talents that any projects needs, too.

And no matter how smart you are, it’s important to stay humble. Because with humility, you will be open to other people, and see new ways of doing things. Humility lets you welcome other people into your project. Pride, on the other hand, is essentially telling people “I don’t need you; I can do things my way.”

By being humble, we also welcome people with diversity of genders, of different cultures, creating a richness in open source by opening to different kinds of people.

The diversity also appears between different projects; it’s almost like languages and cultures of different countries. For example, the community around Linux, Perl, Ruby, and Python all communicate and collaborate differently.

And by being humble with each other, maybe we can see that our project is not the only way, and maybe we can appreciate the ways of other communities.

Now, open source is not all about fun — it’s fun, of course, but it’s also a responsibility. When you agree to participate in a project, you’re taking a weight on your shoulders, and it’s a good thing, as it teaches us to improve ourselves and become better humans.

But life can get in the way — significant others, parents, children, jobs — we may accept responsibility for a time, but there may also be a day where we can’t carry so much responsibility anymore.

So there is a cycle, where you start by assuming more and more of a role in a community, and as life goes on, you gradually take on less and less responsibility. This is entirely natural, and it’s bound to happen in a project’s life cycle.

So it’s worth keeping this question in your mind: “Who will continue my work when I no longer have the time?”

To make sure other people can continue our work, we can think of it as a continuous process: Teaching and sharing the knowledge we’ve learned, and at the same time learning more and more from other people — a continuous process of gaining and sharing knowledge.

Finally, as you work on open source, please be happy, with a smile on your face, and make other people happy! Because this happiness is what gives us the power to make great things.

Do you feel happier now? 🙂

Ubuntu Brainstorm – Contacts Lens

It’s time for another round on the Ubuntu Technical Board’s review of the top ranked items on Ubuntu Brainstorm. This time I’m reviewing a brainstorm about a Unity Lens for contacts, together with Neil Patel from Canonical’s DX team. I volunteered to participate in this reply because I’d already been thinking about how to do it before I saw the brainstorm. I mainly keep my contacts in Gmail these days, for sync to my Android phone and tablet. But, with around 700 contacts, I find the Gmail interface pretty clunky.

The first key to a Contacts Lens is a standard format for contacts, and a path for contact synchronization. For the Oneiric release, coming up in a couple of weeks, Thunderbird is the new default email client, and as part of that, the Thunderbird developers (especially Mike Conley) added support to Thunderbird for the existing standard for contacts in GNOME, which is EDS (Evolution Data Server). Supporting EDS not only provides access to Evolution contacts from Thunderbird, which is important for users migrating from Evolution to Thunderbird, but also provides access to Gmail contacts and UbuntuOne contacts.

The second key is integrating EDS with a Unity Lens. The DX team isn’t working on a Contacts Lens for this in Oneiric or 12.04, but writing a lens is an accessible task for anyone with a little skill in Vala or Python, and is a great way to learn more about how Unity works. I’ll outline how to get started here, for more details see the wiki documentation on lenses. The architecture of a Unity Lens is pretty simple, I’d even say elegant. Writing a Lens doesn’t involve any GUI code at all, you only write a small backend that supplies the data to be displayed. This means that all lenses work for both Unity and Unity 2D, without any changes.

A Lens is a daemon that talks over D-Bus. To build one, you start with 3 files. (Throughout this illustration, I’ll pretend we’re working on a Launchpad project called ‘unity-lens-contacts’.) The first file is the Lens itself, and the core of that file is a few lines that create a Lens object from libunity, and then set some default properties for it. In Vala, that would be:

lens = new Unity.Lens("/net/launchpad/lens/contacts", "contacts");

To go along with the Lens, you need a ‘contacts.lens’ file to tell Unity where to find your daemon, and a ‘contacts.service’ file to register the D-Bus service that your Lens provides. The ‘contacts.lens’ file is installed in ‘/usr/share/unity/lenses/contacts/’, and looks like:

[Lens]
DBusName=net.launchpad.Lens.Contacts
DBusPath=/net/launchpad/lens/contacts
Name=Contacts
Icon=/usr/share/unity-lens-contacts/data/lens-nav-contacts.svg
Description=A Lens to search contacts
SearchHint=Search Contacts
Shortcut=c

[Desktop Entry]
X-Ubuntu-Gettext-Domain=unity-lens-contacts

The ‘contacts.service’ file is installed in ‘/usr/share/dbus-1/services/’, and looks like:

[D-BUS Service]
Name=net.launchpad.Lens.Contacts
Exec=/usr/lib/unity-lens-contacts/unity-lens-contacts

A Lens daemon handles requests for data, but it doesn’t actually do the searching. For that, you need to define a Scope (if it helps, think about searching the ocean through a periscope). A Lens can have more than one Scope, and when it does, each Scope collects results from a different source, so the Lens can combine them into one full set of results. Start with one Scope for one datasource: EDS contacts. A Scope is just another libunity object, and creating one in Vala looks like:

scope = new Unity.Scope ("/net/launchpad/scope/edscontacts");

The search functionality goes in the ‘perform_search’ method. For EDS contacts, you could use the EDS APIs directly, but Neil recommends libfolks.

A Scope can run locally inside the Lens daemon, in which case you add it directly to the Lens object:

lens.add_local_scope(scope);

Or, a Scope can run in a separate daemon, in which case you’ll also need an ‘edscontacts.scope’ file, so the Lens knows where to find the Scope. This file is installed in the same folder as ‘contacts.lens’ (‘/usr/share/unity/lenses/contacts/’), and looks like:

[Scope]
DBusName=net.launchpad.Scope.edscontacts
DBusPath=/net/launchpad/scope/edscontacts

That’s the basic anatomy of a Lens, and enough to get a new project started. To see how it all fits together, there are several good examples of other lenses. The Unity Music Lens is the most relevant example for the Contacts Lens, and a fairly straightforward one to start looking at. For more complex examples, see the Applications or Files lenses. There’s also a Sample Lens, which is a working tutorial. And, once you get the core of the Contacts Lens working, and are looking for what to add next, read up more on Categories and Filters in the wiki.

If this sounds like an interesting project to you, drop us a line. You’ll find a lot of enthusiasm, and willingness to help out where you need it.

Allison Randal

Category Archives: tech