How Software is Built

The State of Local SEO: Industry Insights for a Successful 2019

Posted on by Carlos Kelly

Local search marketing acts as a connection between your business and real-world communities. This bridge leads to those places where you have consumers living, working, and making the vast majority of their total purchases. These are also the places where the competition is more intense than ever.

Local SEO Trends in 2019The local marketers today are faced with more questions than do they have answers. Is Google really stealing website traffic? Is there a way of fighting the giants such as Amazon? Here is a look at some industry insights that can help you plan your game in 2019.

First, some important takeaways

·         Versatility is the keyword for local search marketers to succeed:

Local search represents an ever-changing and growing field that constantly challenges marketers to keep pace with the trends. It doesn’t matter what your company deals in – the marketer today needs to have both the big picture as well as the little details in mind.

·         Clients have little knowledge about local search:

Simply having great tactics will not help you succeed as a marketer today, you also need to learn how to be a great communicator. It is difficult to get clients on board with strategies for their understanding of metrics and goals is vague. Also, with SERPs becoming ever more complex, it is getting harder to teach them. Get more insight into understanding the modern SERPs, and it is important to rank number one on the local search.

·         There is more to local marketing than merely search:

Google lacks any severe competition, and paid results are becoming more popular. Hence, local search marketers have chosen to broaden their scope of work. The importance of SERPs can never be ignored but the focus today has shifted to alternative platforms such as real-world community building, word-of-mouth, and email. Local businesses tend to give added emphasis to Google. Being able to locate other marketing opportunities will allow your company to stand out.

The State of the Industry

·         Proximity is an important factor in local rankings:

How close your prospects are to the business will have a significant impact on whether you will show up in their Google search results. Sadly, there is little you can do in this regard apart from moving your store to a densely populated area.

·         Searchers usually have a terrible experience with local search:

A person searching for pizza could be willing to travel certain distance for a slice with a higher rating. Google’s algorithm gives more emphasis to proximity, and the top results are shown based on the location rather than the quality. It is a common sight for marketers to find poor-quality businesses ranking higher than their counterparts who are better thanks to their close physical proximity to the searchers.

Google needs to do something about improving this overemphasis on location to give an improved search experience.

·         SEO is an investment that pays:

Marketers who lack sufficient knowledge of SEO often tend to be skeptical of its value and can be assured when provided with the right statistics. More time people devoted to SEO, better were the observed results post an Algorithm update rolled out on August 1.

This result holds true for both marketing agencies and in-house marketers, and there is no difference in outcomes between the large and small companies.

·         Google is becoming the new “homepage”:

There is more information displayed on Google today, and it also allows transactional activity within its own interface. As a result, there is little need for searchers to visit a local business website. People seem to think that these efforts (or the lack thereof) are having an impact on the local businesses.

The worth of a website remains the same, but it has become all the more important for local businesses to give higher priority to managing every element of their Google presence.

·         The relation exists between organic and local rankings:

There is a common feeling that reduced organic traffic has given local businesses a chance to do away with their websites. Marketers report that a brand with high visibility in local features of SERP also enjoy a high organic placement.

Google is fast turning into the new homepage that local businesses are turning into even though the organic authority of a company’s website is what continues to support the local rankings.

·         Reviews have an impact on the local rankings:

Google reviews have a strong impact on how your local business ranks in the local pack. Many business owners seem to misunderstand reviews – they can be any nuanced signal about your business including keywords in the review text, customer sentiments, recency, and ratings. As a local search marketer, you need to consider every aspect of review while designing your digital marketing strategy.

If you are based in New York, you can work with experts from New York City-based SEO services who has high-quality resource data and someone who understands the sentiments of business and expectations that their customers may have from them and accordingly build a customer-centric marketing strategy.

Strategy for Local SEO

·         There is greater emphasis on revenues and conversions:

Focusing on ConversionsIn the past, business owners showed too much emphasis on traffic and rankings. However, the focus has drastically shifted toward revenue and conversions. Nevertheless, there is still a lot of work to be done since almost one-third of marketers continue to emphasize rankings and traffic over the end result of conversions and revenues.

·         Local SEO does not have such a thing as “great training”:

The value of training is well-known to marketers, but two-thirds are of the view that they are not getting the high-quality resources and training that is needed for doing an excellent job in local SEO. Local search engine experts should improve their knowledge and resource sharing to educate the marketers better.

Tactics for Local SEO

·         Local businesses are overlooking link building:

A third of digital marketing teams don’t have any strategy for link-building which means they are already handicapped on a competitive front. Domain authority is strongly linked to local search rankings, and link building is something that should not be overlooked.

Those who do emphasize link building, follow direct asking and contact development as the primary tactics while event hosting and sponsorships occasionally find mention.

·         Email marketing is catching up, at last:

If there is one strategy that gives consistent high returns on investments, it is email marketing. The fact that more businesses are adopting it is only good news for digital marketing experts.

However, many still remain skeptical about its powers while others just don’t know what to do with it. There is a long way to go before it becomes the go-to strategy for local businesses looking to improve upon their revenues and conversions.

Digital marketing has come a long way in recent times, and the numbers are only getting better with each passing year. However, there is still a lot of untapped potentials that it has to offer especially for local and small businesses to help them grow better and become powerful entities in the local marketplace.

Read more

Interview with Joe Brockmeier – openSUSE Community Manager at Novell

Posted on by Carlos Kelly

In this interview we talk with Joe. In specific, we talk about:

 

Sean Campbell: Joe, to get us started, could you give us a little bit of your background?

Joe Brockmeier: OK. About 1999, I started writing about Linux as a freelancer. That eventually morphed into a career writing about Linux and open source as a technology journalist, more or less full time, much of that time as a freelancer. Around 2005, I joined Linux.com as editorial director, and then last year, I was with “Linux Magazine” as editor in chief. My educational background is in journalism, and that’s when I discovered Linux–when I was in university.

But last fall, Novell came and asked if I’d be interested in applying for the community manager job, which at that time was called the chief Linux evangelist. Having followed the open source community for so long, I was really interested in being directly involved with the project, as opposed to just observing and writing about what open source communities were doing, so I joined Novell in February as the community manager and have been pretty much going non-stop since.

Back in August 2005, openSUSE got its start when SUSE announced that they were going to start a community distribution. Prior to that, SUSE Linux had been developed in-house by SUSE before they were purchased by Novell, and while it was a very strong distro, there really wasn’t much community input into it. Novell decided to build strong community participation.

The project is going on about three years old now, and we are making pretty good progress regarding getting the infrastructure in place for external contributions and having transparent development.

We just announced last week the 1.0 release of the openSUSE Build Service, which adds the ability for external contributors to make direct contributions to the distribution, as opposed to going through the gatekeepers, so to speak. And we released openSUSE 11.0 in mid-June, with a lot of improvements, particularly in the installer and the package management, and of course all the normal improvements that go along with a version upgrade, such as new versions of KDE and GNOME and things of that nature.

Sean: Tell us a bit about where you feel openSUSE sits in the landscape of desktop distributions. What do you think it’s exceedingly good at, and maybe some of the places where you see challenges or opportunities?

Joe: Generally, my metric for success on the desktop is how well it fits what people need. I don’t really spend a lot of time comparing it to other Linux distros, because I really think we all have the same mission, which is to get people using Linux. So I don’t view them as competition, so much as inspiration, if anything.

The audience we’re trying to address includes home office users and others who want a good, solid desktop operating system that’s as easy to use as possible.

I think openSUSE is exceedingly good at package management, being easy to use, offering a top-notch desktop experience in GNOME or KDE, and providing a wide range of the best free and open source software available.

Our challenge is reaching new users and encouraging more users to become contributors.

The opportunity, right now, is that a lot of people are put off by Vista and are looking around at their options. I want those folks to find openSUSE, and another challenge we have is to find ways to make the jump from the audience that’s Linux-aware to the vast number of potential users who haven’t heard of Linux or know very little about Linux.

Sean: Every distribution seems to have an area that they don’t go after, or that they maybe feel they don’t have as great a degree of fidelity in. Is there some area where you think that’s true for openSUSE, where it’s not particularly geared for?

Joe: I was at Sun CommunityOne, and we had a Linux distro panel that included me, Jono Bacon from Ubuntu, Karsten from Fedora, and Glynn Foster from Sun. We were talking about this.

I think the only major difference is that we have slightly different philosophies. Fedora wants to approach the desktop with only free software, and they don’t want to ship anything that is proprietary at all. On the other hand, if you look at the retail box and the DVD that we ship, we include a little bit of proprietary software like Adobe Flash that we think people who are coming from Windows are going to want.

As much as I don’t like the fact that you have to have a proprietary program to view a lot of web pages, I think that that’s reality. If my girlfriend’s kids use a computer, they’re going to go to web sites that require Flash, and they’re probably not going to be sold on the argument that since it’s not free software, they should just not go to those sites.

I think it’s more important to successfully get people to use a 98 percent free software desktop than it is to ship a 100 percent free software desktop that no one wants to use.

Sean: So maybe we have to be OK with the idea of shipping a proprietary 3D driver because everybody has EVO integrated right now. We can either tell them to go spend seven days configuring it when they’re not competent to, or we can just roll over for two percent of what’s going to be in the distro.

Do you feel that’s kind of what’s going to have to happen in the interim, and then eventually the hardware manufacturers and the other folks will ship Linux drivers, and then maybe that’s not an issue as much anymore?

Joe: Yeah. I think it’s a major chicken and the egg thing. You have to demonstrate that you have a certain percentage of the user base before you can expect companies to spend engineering time or be willing to do things differently than they have in the past.

I don’t buy the argument made by a lot of the manufacturers that they have to have proprietary code to be competitive. On the other hand, I do think it’s necessary for us to make the argument to them that there is some benefit to them when they ship a free software driver.

And the first thing that we have to accomplish there is to demonstrate that there are enough users that it will make an appreciable difference in the number of units that they would sell.

Scott Swigart: What’s the relationship between openSUSE and Novell’s enterprise distros for the server and desktop?

Joe: Basically, openSUSE is the foundation of SUSE Linux enterprise. We just released 11.0, and now we’re working on 11.1, which will be the foundation of the SUSE Linux Enterprise Server and Desktop products. The appropriate technologies that we develop in openSUSE are carried over into the enterprise product.

Scott: Would it be accurate, then, to say that newer technology might show up there, and then a decision is made in terms of what’s ready for the SLES and SLED distros?

Joe: We do sort of incubate technologies within openSUSE, although we also work on things that are of benefit to the openSUSE community that may not have an impact for our enterprise customers.

We are also careful to make sure that whatever we ship in openSUSE is usable and stable enough that our users are going to be satisfied with it and happy with it.

Scott: What are the usual things that you do when you’re putting together a distro? Where does the work of the upstream project stop and your work start?

Joe: In some cases, there isn’t a great deal of difference. For example, we have a team that works on GNOME, and we try to do as much work as possible within GNOME so that there’s not that loss between the upstream project and the distribution.

To illustrate one of the problems historically between distribution and an upstream project, say you have Fedora and Ubuntu and openSUSE and all these other different distros working on something. You get business when one project decides to innovate in one area or add a few patches or whatever, but those changes don’t necessarily make it upstream, or they do make it upstream but after the main project has also started working on the same feature or problem in tandem.

As much as possible, we try to work within the projects like GNOME for KDE that benefit us, rather than doing the patches in our little area and then maybe submitting them back, or letting them get them, or whatever.

Obviously, for the desktop, we add our own artwork and some polish in those areas. We also make some configuration decisions that may be aren’t handled by default GNOME or KDE, but largely, we really try to work with the upstream projects to avoid duplication of effort and that sort of thing.

Scott: How do you handle it when you identify upstream work that would be valuable to your customers when that work is produced after the last stable release?

Joe: For example, we knew the Mozilla folks would be shipping Firefox 3 sometime after we shipped openSUSE 11. We had to make a decision about whether we should stick with Firefox 2, which would be pretty old midway through openSUSE 11.0, or whether we should go ahead and ship a pre-release version of Firefox 3.

Ultimately, we decided to go ahead and ship Firefox 3 beta 5, and when the feature freeze came into effect, we stuck with that version. Since then, we’ve gone ahead and shipped the final, via the package updates.

For community distribution, it’s easier to do that sort of thing, because we don’t have the five-year enterprise contracts to worry about, which gives us a little more flexibility.

Scott: What about the smaller projects, like Pulse Audio, an IM client, or Pigeon, when there’s maybe not an official release, but you want to back-port a really important patch to the version you’ve shipped?

Joe: Generally speaking, the policy would be that if there is a security fix or something, we would back-port it. We usually don’t do full-version updates or anything like that, with some exceptions for major apps like Firefox. As for new features, though, we have a rapid enough release cycle that it makes more sense to just put the new features into the next release.

Sean: Let me ask you a question in a different area. Generally speaking, in the open source community, there’s a somewhat mixed reaction to Novell having agreements with Microsoft. Do you feel that any controversy in that area affects uptake of openSUSE?

Joe: When I took the job, that was one of the first things that I expected a lot of questions on, and I did at one time because everyone thinks that it’s the elephant in the room. But when I go to open source conferences and talking to users and whatnot, I generally haven’t found it to be as big of an issue as is generally suggested in the press. This is not to say that it’s not an issue at all, but it’s hardly the only issue, and after nearly two years, a lot of people have realized it’s not the catastrophe that some painted it as when it was announced.

I think there are some folks that are very active online trying to complain about this particular issue, and they’re welcome to that viewpoint. I would suggest that maybe if you are deeply committed to open source, perhaps

Read more

Interview With Joseph Hill – Mono

Posted on by Carlos Kelly

In this interview we talk with Joseph. In specific, we talk about:

 

Sean Campbell: Joseph, would you introduce yourself and tell us a bit about Mono, Moonlight, and the kinds of stuff you work on?

Joseph Hill: Certainly. I am the Product Manager for Mono at Novell, which gives me the great privilege of working with Miguel de Icaza, who is the founder of the Mono project as well as GNOME and several other open source projects. Mono is an implementation of the .NET framework that is open source and available for Linux and Macintosh as well as Windows, Solaris, and any other platforms that people want to run .NET code on.

When Microsoft came up with the .NET framework and the CLR (common language runtime), they took steps to make sure that it would be available as a standard. They wanted to get participation from people involved in designing languages and runtimes, so they submitted their specifications for the runtime and the C# language to ECMA.

Miguel chose to implement Mono because he saw that C# is a very nice language that solves a lot of problems elegantly, so it would be a nice language to have available as an improvement over C and C++. The first target for Mono was for Linux desktop applications, where they built and offered GTK# as an improvement over GTK and GTK+, which is a graphics toolkit for the GNOME desktop.

The project started in 2001, around the time that .NET was entering beta. It has progressed from there to encompass a lot more of .NET. Since those initial libraries, Mono has taken on ASP.NET and WinForms implementations, and it has been used in various interesting circumstances.

Sean: There is a certain amount of skepticism about Microsoft in the open source community; people are always wondering what they are “really up to.” I would imagine that people must ask you fairly frequently why they would develop under Mono for Linux, instead of using Java or Python or PHP.

Joseph: I think it ultimately comes down to individual preference, and there are actually several different parts to that question. C# is a nice language, and we think it is an improvement over Java, because Microsoft had the opportunity to look at Java and to identify enhancements that they could make in a new language that Java couldn’t or wouldn’t.

That is part of what makes C# attractive, and beyond that, the runtime is capable of running code written in VB or several languages that target .NET today. That includes everything from the classic example of COBOL to the newer DLR focused languages like IronPython, IronRuby, and so on.

Mono means different things to different people. Some may want interop, while others want to consume libraries written in one language from another language.

Sean: One of the things that everybody points to in terms of building an ecosystem for their platform is the list of applications that are on it–they always have a marketing slide that says, “We have 3000 ISV applications.”

When you are out there evangelizing and touting Mono, what do you usually point to?

Joseph: If we do go back to the beginnings of Mono and GTK#, once we got a working GTK#, we at Novell started building a lot of applications. We were shipping .NET applications in Linux well before Microsoft was shipping any .NET applications bundled with its operating system, such as Beagle and F-Spot, which are desktop search and photo management applications, respectively.

The community also built several popular applications like Tomboy, which is a note taking application that is actually considered part of the GNOME standard desktop now. So, there are a lot of popular applications on Linux and a community there.

There are also ISVs such as Medsphere shipping GTK# applications that basically chose Mono because they like .NET and they wanted a good cross platform story for the product they offer in the healthcare industry.

This historically has been the story of GTK# on the desktop, because we ship a very nice desktop, but with the state of Mono today supporting ASP.NET and Windows Forms, we are working to get library vendors and third party control vendors that ship managed applications or managed components to certify that they work on Mono.

Sean: It sounds like you guys are really collecting and putting a lot of evidence out there to show people that this isn’t just kind of a hobby; people are doing real stuff on this. People are making business decisions based on the viability of Mono to be able to run production code on Linux, and it gives them reach across more platforms and it provides a lot of advantages for them.

Joseph: The fact that I have been hired into the role that I am in is a clear indication that Novell feels Mono is ready to be used for more than just the applications we have been building. Going forward, we are working to attract ISVs to the platform as well as building out end user customer stories, where people have chosen Mono to deploy on and to build for.

We think that that enhances the story for being able to take customers that have already chosen .NET as their platform, but don’t want to be limited to just Windows as their target. We give them a way to grow their addressable market.

The other indication I can give is that we are releasing Mono 2.0 in October. That version number is really a statement on our part that Mono is ready to support what customers want from .NET 2.0. .NET is a really big platform and it just gets bigger with every release, but the portions that customers are using tend to cluster around specific functionality.

ASP.NET has been around for six years and has a really huge part of the web’s market; we support applications based on ASP.NET 1.1 and 2.0 and AJAX very well. Beyond that, the majority of what people are doing with ASP.NET is 100% managed.

At this point, customers have ASP.NET applications that don’t depend C++ code, and very little ASP still exists in people’s code base if they have adopted ASP.NET as their platform. Mono can do these things really well without the need for full implementations of WCF or WPF and other recent additions to .NET.

Sean: What challenges do you have in trying to shadow the .NET development process? We talked to the head of the Wine project, and it was interesting to hear about the challenges that surround shadowing the Win32 API. What challenges have you faced, and what observations can you make about the evolution of the framework, given how close you guys have to follow the development process?

Joseph: To rewind back to the beginning of the story again, initially the goal of the Mono project was not to emulate what Microsoft was doing; we really just wanted access to the runtime and the C# language. ASP.NET 1.1 was very small and very simple, and it was implemented by very few engineers in a relatively short amount of time.

ASP.NET 2.0 grew a lot from that. It definitely added a lot to the library and the APIs increased by something like 10 fold, but we still had a working ASP.NET 2.0 implementation becoming complete by the end of 2006 when ASP.NET 2.0 had come out in 2005. Even though we are releasing Mono 2.0 today, the 2.0 release has largely been held up by our WinForms implementation rather than the ASP.NET implementation.

Ultimately, we had to add WinForms to the project because we saw increasing demand for it. When we first released Mono 1.0, we didn’t really have a WinForms story, even though we had an ASP.NET story.

We weren’t even seeing that much of an uptake of WinForms or a large desire to try to emulate it, but as more customers writing desktop applications began to adopt the Windows Forms platform, it became evident that people expected Mono to have that.

That was when we really saw the need to make the decision to start chasing the API. My personal view is that it creates its own set of problems, and I’m sure we have a lot in common with the Wine project in that regard. Things don’t always work as they are supposed to or as advertised, but you have to match the implementation and the behavior of the existing implementation.

WinForms applications tend to have more of a legacy than ASP.NET applications, where somebody had a desktop application and desktop components that may have been around for a lot longer than the company’s adoption of .NET, and those components tend to live on.

Sean: Do you guys have to rewrite every assembly from scratch? On the one hand, there is the low level stuff that is going to be called into the API, but then on the other hand, in the .NET framework there are higher level control libraries, and they are not calling directly into Win32 APIs; they are just calling to other parts of the framework.

Do you have to re-implement those as well, or are you able to just carry some DLLs that are part of the .NET framework on Windows as part of Mono?

Joseph: From a licensing standpoint, that is not allowed, so we write our own implementations for all of those. That does cast light on our WinForms implementation. We took a couple of stabs at it, and the first time around, it was going to be a wrapper around Wine, actually. There were various difficulties with coordinating changes that we had to make to Wine to get our implementation to work right, and it was complicated getting those patches accepted upstream.

Scott Swigart: That’s interesting, because I have wondered whether you ever considered just building something on top of Wine–maybe focus building an IDE and the higher level abstraction while letting them figure out how to make the framework talk lower down.

It sounds like you eventually found it easier just to take it on yourself.

Joseph: That approach let us avoid that dependency, and leveraging Wine for what we are doing was also a bit architecturally convoluted, relative to the 100% managed implementation that we ultimately arrived at. Basically, we draw every component using System.Drawing, which means we have an unmanaged GDI implementation, and we call into that from System.Drawing.

All of our components are managed, whereas Microsoft’s were all wrappers around existing Win32 controls. That ultimately gave us the benefit that, once you have a System.Drawing implementation working on a platform, you are capable of running WinForms on that.

So, dropping that Wine dependency actually worked out really well, because now we have WinForms running on Mac without a Wine dependency. All you need is Mono and GDI, which we make available in our Mono installation, and then you have access to WinForms.

Sean: What do you think about the potential impact of virtualization on the desktop? Do you see a possible future where you would focus more on IDE development and interprocess communication between two OSs’ different apps, and less on trying to build a portable dev platform and framework?

There is still benefit to that, even in a world where everybody is drawing a virtualized set of partitions on a machine, but do you guys ponder that from day to day? Do you wonder what the impact of KVM on the kernel will be, how you leverage it, and that kind of thing?

Joseph: I wouldn’t say we think about it from day to day, although of course, we keep an eye on adoption and how the Linux desktop is enabled or hindered by virtualization

Read more

Interview With Warren Woodford – Founder Of Mepis

Posted on by Carlos Kelly

In this interview we talk with Warren. In specific, we talk about:

Sean Campbell: Warren, could you introduce yourself and tell us about some of the things you have worked on during your career?

Warren Woodford: Sure. I’ve been pushing electrons for a very long time. I grew up with what is now the computer industry, and I was already working at almost the VP level when the first microcomputers came along.

My background includes telecommunications, entertainment, field service, mini computers, micro computers, mainframe computers, PCs before they were called PCs, real time processing systems, software for business, software for home, software for government, and tools that people have heard of if they’ve been around a long time–always on the bleeding edge.

That’s the way I worked until the Internet bubble burst, at which time I kind of withdrew and decided to take it easy while the economy was down, not realizing it was going to be so volatile for so long. It was in 2000 or 2001 that I first started looking at Linux.

Aside from the philosophy and technical foundations of Linux, there was a lot there that I really didn’t like, frankly. Because of my background, I had been a champion of GUI interfaces since the early ’80s, and that aspect in particular was very inadequate at the time.

The bottom line is that, when I first found Linux, it was too rough around the edges for me. That represented the possibility of opportunity, not that I was really looking for work. This will piss off a few people, but there was a certain amateur quality about it.

Around 2001 was the first time I used a version of Linux that felt pretty good, which was SUSE, but it also had some significant bugs. It was pretty mature, but it was stiff–just too rigid in the way it did certain things. Mandrake seemed like it was on the right track, but there were bugs in the installation process and things like that.

Still, I felt that there was promise, so I started using Mandrake around 2001, and as I got familiar with everything, I decided that it was marginally good enough. Then, in 2002, Mandrake stumbled badly with their release in the September/October timeframe. They made some big mistakes, in part because of pure hubris.

It was around that point that I started thinking about building a version of Linux, instead of depending on other people. I jumped into it, deciding to pursue it as a way to learn technology that I didn’t know.

It has always turned out that when I learn a new technology, opportunities arise, whether my original reason for getting involved worked out or not. That’s how I got into Linux and decided to develop MEPIS. It was first for myself, and then I decided to see what would happen if I gave it free reign.

It got picked up by Distrowatch and went to #10 in one month, and that told me something. I started spending almost all of my time on it, but then in 2004 I had an injury that laid me up for a long, long time. During that time, MEPIS made it to #1 at Distrowatch, but I couldn’t really do much to maintain it.

Then it slid. Mark Shuttleworth saw opportunity and forked Ubuntu off of Debian. To be clear, I think that has ultimately been good for Debian, and Ubuntu contributes a lot back to the Debian community, but it is clearly a fork.

Sean: What do you think about Ubuntu’s strategy? They contribute upstream–more as of late, in fact–but at the same they time fuzz the distinction for users that Linux is really a collection of sub projects that are traveling in the same direction at roughly the same velocity.

I actually think what he’s trying to do isn’t all that bad, but I may have the luxury of some detached pragmatism. I see it as a logical, commercially driven decision, but I’m curious what you think about it, because you’ve obviously got a lot more history in this than I do.

Warren: I’m not bothered by anything that Ubuntu does. I think that Ubuntu pushes the boundaries regarding purity, and I don’t think that’s a bad thing, although that gets me in trouble with some people.

Some people call me a whiner about the GPL, while from my point of view they are the whiners. The GPL deserves to be scrutinized closely and to be debated, as does any legal document that restricts people’s rights. Calling a person a whiner because they care enough to challenge, question, or state positions about something is itself whining.

I think it’s good that Ubuntu challenges the boundaries regarding what is and is not proper open source. I think that what Ubuntu contributes back, both upstream and cross-stream to Debian, is good. And I think that the way that they kicked Debian in the collective butt has been good for Debian.

The fact that Mark is out there trying to make commercial deals actually may or may not make a big difference in the long run, but it’s not necessarily a bad thing. For example, I know that a couple of years ago he negotiated with IBM to get Ubuntu approved as a platform for running DB2. That would make it very easy to get that DB2 approval extended to Debian if anybody wanted to, and I think that’s OK.

From the point of view of what’s right and wrong, I don’t think there’s anything at all wrong with their fuzzying things a bit, as long as they don’t do it as much as Xandros did. Xandros at one point was blatantly changing copyright, renaming things and such, to make it appear that they had invented KDE or something. I can’t speak for what was in their mind, but something was going on there.

I don’t see Ubuntu doing that. I see them creating projects of their own to build utilities that represent their philosophy about how such things should be done, like the Adept project for a package manager. However if there’s a good product out there already, then there’s no good reason for them to be reinventing the wheel.

I think KPackage has been kind of so-so. On the other hand, I think Synaptic is awfully darn good. But Synaptic is GTK based, and while that’s not necessarily a bad thing, I wouldn’t program in that world. For personal reasons, it would be too inefficient and take too long to do. I wouldn’t program in Python for the same reason.

I don’t see anything wrong with creating or sponsoring Adept, just as I don’t see anything wrong with the idea of starting Ubuntu in the first place. You can complain or you can say that competition’s a good thing.

Mark, for one, is probably not going to pursue something unless there really is a shortcoming to be addressed.

Sean: What about Ubuntu’s OEM strategy? They have done really solid work in getting Toshiba to push Ubuntu, for example, and of course they also have Dell with five systems. They seem to be doing a really bang up job in getting OEMs to ship, promote, and push the Linux based desktop, and that doesn’t even count the netbooks push that’s happening.

Do you think they may have figured out a strategy that could give them a certain position on desktops that others haven’t quite figured out yet?

Warren: An important consideration is that Mark is more or less a billionaire, and he made that money in the computer industry. He can talk to companies like Dell, IBM, Toshiba, and others with a level of credibility that no one else in the Linux industry that I’m aware of can match.

He can get in the door to propose things, and he can get things agreed to that nobody else can. That gives him an advantage when you consider one distro over another, but that’s just how things are.

That’s good for Linux as a whole, and it means that companies like Dell and Toshiba are starting to think about compatibility more than they were before. And that’s a good thing. There are people who have told me, “Hey, this is really great. I bought a Dell machine with Ubuntu and then put SimplyMEPIS on it and it all worked.”

Sean: You’ve got Intel producing video drivers and wireless drivers and you’ve got network managers, so this is where the Ubuntu fuzzing works both for and against you. On the one hand, it makes the user feel like the network manager is Ubuntu’s network manager, even though it isn’t, really. On the other hand, they can just go stick a different distro on it.

Warren: Yes. In that regard, they’re having a positive impact on Linux compatibility with mainstream hardware, by getting the mainstream hardware companies to think a little bit about compatibility.

Scott Swigart: How much difference is there, from an application developer’s perspective, between different Linux distros? And how much work is that to take into account, and how much does something like the Linux Standard Base help with that?

To put it another way, for an application developer, how much effort is it to support and test and ensure that you’re compatible with lots of different Linux distributions? And how much of that work is done by the app developer versus the distros themselves?

Warren: That is a very big question. About three years ago, some of the biggest companies in the computer industry brought together some Debian affiliated companies like mine regarding this very question. They wanted to explore having Debian-based Linux as a competitor for Red Hat and Novell, and it gave rise to the ill-fated Debian Common Core Consortium.

Those conversations arose from this very issue. You couldn’t have commercial applications or commercial support for a particular Linux distro without a known, stable base. That plays out at different levels, because it depends on what kind of application it is. If it’s something for server, then probably, you only care about a core set of packages.

You can have a core set of packages, and you can have standards around that. If you do, then at the very lowest foundational level, companies that are considering something commercial related to Linux have a common base that they can rely on. But what’s the real core if you’re running a practical application?

And if we’re not using straight X, then what toolkit are you using, and what version? Consider the case of Acrobat Reader for Linux. How are you going to release Acrobat Reader in a way that runs cross distro, when each distro and each release of each distro may have different versions of key libraries?

Adobe does it by basically bundling those libraries, so they only have to rely on the very minimum number of compatible packages, or libraries, on a particular release.

From the point of view of an application developer, the problem is that every distro and every release of every distro has variations in what versions of core packages are installed. And because each distro has a different philosophy about long term maintainability and about stability of the distro, it’s a moving target forever.

You know, it’s a miracle that Firefox works so wonderfully. Those guys are incredible, and so are the Open Office people. Figuring out how to write code that is compatible with so many different versions of libraries to run with or be compiled against is a huge job. This is where Linux has a really big disadvantage when it comes to building complicated applications that you want to distribute broadly.

Scott: Educate me on the Linux

Read more

3 Basic Things All Internet Marketers Need to Know

Posted on by Carlos Kelly

A successful internet marketing strategy isn’t just made up of one strategy. It combines marketing data and various SEO techniques which results in driving targeted traffic to a website and ultimately, increased sales. Internet marketers need to know what strategies are available to them and how to use them to capture a solid customer base. The “how” in this strategy involves understanding who your customer is and why they purchase. Here are three basic things that all internet marketers need to know to get started.

Basic things in internet marketing1) Internet marketers need to know their audience

Most online marketers don’t receive the traffic they desire because they have only a vague idea and understanding of who their target audience is. The problem with vagueness is that marketing efforts are too general to attract any specific customer base.

Marketing data includes consumer demographics and other information such as where do they buy or how do they search online for a product or service. Internet marketers benefit from these clues by knowing where to market online and which marketing strategies to use. Keyword selection becomes more targeted on a website, in the product or service description pages, and in a pay per click marketing strategy. Online content and customer correspondence become more tailored to a specific customer.

To find marketing data information, try searching online. Include keywords such as “consumer data” or “marketing data” to a niche topic. Another great place to research is a competitor’s website. Study their site and look at how competitors are reaching for customers. Look for keywords and link strategies used.

2) Internet marketers need to know how to pull in web traffic

A successful SEO strategy is basically made up of utilizing keywords, backlinks and learning the strategies that drive traffic to a website. Here are some ideas for pulling in web traffic:

Create keyword content – Use keywords in site web pages, articles, site descriptions, photo and video descriptions, including social networking pages.
Capitalize on social networks to promote business. Social media is one of the easiest forms of online marketing to start and maintain and it’s also where the people are. Social networks such as Facebook, Twitter and LinkedIn have daily users that number in the millions and that number is expected to continue growing.

Employ as many SEO techniques as possible. Consider creating a pay per click strategy, using videos, photos, podcasts, and articles to get the message out. Continuously research keywords and work on linking strategies that improve page rank and authority.

3) Internet marketers need to know how to monitor and optimize their website using data from web analytics

An internet marketer who doesn’t use web analytics is like a sharpshooter who doesn’t know if he hit his target. Web analytics let online marketers know the number of people who visited their site, which search engine was used to bring in traffic, and how many pages visitors viewed while on a site. More advanced analytical tools can track other pieces of information such as how long visitors remained on a site and even if the visit generated a sale.

Internet marketers can track the increase in traffic drawn in by a pay per click marketing strategy or an SEO submission to a directory. They can also track the success of a keyword SEO strategy. If an internet marketing strategy doesn’t work, web analytics will let marketers know that as well because there would virtually be no change in traffic results and online sales.

Internet marketers who know their customer base and how their customers make purchasing decisions save themselves from wasting their marketing budget, time and effort on strategies that don’t work for their type of business. They are better able to reach their target customer because they understand their customer’s needs and how to deliver exactly what a customer wants.

Read more

The Media Maze: Time and Tide

Posted on by Jim Meskauskas

As I was sitting in the large, darkened room full of media and marketing professionals at this week’s media summit, a comment was made by one of the speakers that got me thinking, as comments made within earshot often do.

Alan Schulman, co-founder and chief creative officer a digital marketing agency, said that his shop has seen that more people are spending time with online assets that far exceed what we typically see in other media. He suggested that what is needed to evaluate modern media is a new metric that looks at “time spent.”

He is right in saying that an additional metric addressing the level of engagement as indicated by the time one spends with a medium, its vehicle, or the brand represented in the environment should be included in the evaluation of media.

Entering the maze of new mediaBefore rolling your eyes, sighing with fatigue, and grabbing your bottle of Maalox at the thought of yet more data to have to go through, let me explain why this notion is so valuable. In fact, it may be valuable enough to replace other metrics and even lead to a new way of looking at media inventory.

I want you to want me

“The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men.” This may be a little hyperbolic, but it is accurate to say that the attention of the modern consumer is under assault at all times from every direction. Their lives are filled with work, kids, extracurricular activities; their children’s extracurricular activities, media, and marketing messages — the frequency and number of which are becoming legend. The disparate demands on our consciousness are forcing us into a place where we can only just manage the components of survival; attention, like a plum, loosing a little juice every time you slice it.

In this competition for a piece of your mind is your own peace of mind. To find this, people are consciously and — in order to survive — even unconsciously tuning out what they can when they can. Among the contestants for the prize of attention to be the first to go is advertising.

People have demonstrated a willingness to allocate what little attention they do have to finding ways to avoid advertising (ad blocking software, spam filters, DVRs). As a result, advertising has become a game of dodge ball, with advertisers throwing the ball and the consumer doing everything he or she can to avoid getting hit.

Attention does not just consist of focus, however, but of time. The more time I spend with something the more of my attention it gets.

Pain, fear, and urgency are all effective states advertisers could induce to cut through the clutter and demand our attention (anti-drug advertising is an example of this; so, too, if you think about it, are pleas for assistance and donations from charity organizations). But most brands can’t, shouldn’t, and don’t want to wield such forces. So, what can they do instead?

Coax people into spending more time with a brand.

The only way to get this done in the modern media environment is integration across media platforms. For the time being, I cannot get more engagement with my brand out of an audience than the time allotted me with broadcast. Print is a little better here, in so far as an individual can read your copy and look at your images over and over again for as long as he or she wants. But the protocol is still fixed.

Online, and now portable media platforms like smartphones, I am no longer confined by time and space. If you look at DVRs and podcasting as a means to time shift media usage, one could argue that even broadcast is no longer really restrained by time and space. It is now possible to fill a person’s hours and his or her imagination if and when that person comes seeking brand engagement for as long as he or she chooses to be engaged.

Advertisers in the entertainment categories (movies, music) have been regularly taking advantage of this feature of new media. Product with such a short shelf life needs to live beyond its location of primary engagement if it seeks to maximize its value. A film seen once is great when millions and millions see it. But a film that creates a community of people interested in it allows those people to be involved in ways beyond it just being a film and lends it longevity.

Pharmaceutical companies, too, are using the internet as the primary point for distributing information, letting the television serve as a teaser to peak interest on the part of the audience and thereby creating the conditions for more time spent with the audience and the development of a more quality relationship.

Strategize to build customer engagementStock-in-trade

Could time spent with a medium become a unit for sale?

For media companies as a whole, currency has been shaped as some form of time. Certain kinds of people spending time — even just a little — with your media product could translate into premiums not derived with other audiences, but essentially, a media product wants people to spend more time with it. A broadcast or cable network wants you spending more time with it over another and attempts to accomplish this with programming that you find more interesting, entertaining, and engaging. A publisher wants you spending more time with their magazine in your lap than another magazine. The more time you have a particular radio channel tuned in while you are stuck on the freeway, the better it is for that station.

In online, if I can determine how long a unique visitor spends on my site, why not break that time up into units and sell media inventory based on that, rather than the fleeting and quickly forgotten impression?

Back in the olden days, like, in the late 1990s, sites loved to talk about how long visitors stay. Gaming sites bragged that the average visitor was there for umpteen minutes per day. comScore and NetRatings both report on average duration of a visit. Within a short time, however, session lengths were no longer touted as a point of differentiation. But what does any of this mean if there is a different ad popping up on the page each time a unique visitor clicks on something?

The length of time a user spends at a site is not very meaningful to an advertiser buying impressions because what determines the likelihood of a visitor seeing your ad is a function of the rest of the activity of the site, the number of pages visited, and the placements of your creative. The chance of an advertiser’s ad being seen is only as long as it takes for a unique visitor to click to his or her next location.

So why not sell units of time for online media? An impression is so fleeting in the online space that it’s hardly worth much except for a strict direct-response buy. In the awareness/branding world, it takes more than a second to make an impression.

By looking to an inventory standard that allows an opportunity for an advertisement to have impact, that is, the time spent with the medium and, thusly, the brand, we might get closer to having a real sense of effectiveness.

Read more

Is Security Really That Hard To Measure?

Posted on by Carlos Kelly

There’s a good article on LinuxWorld about the security debate between open-source and Windows. My first question is, does it need to be a debate? In this day and age, isn’t it easy enough to quantify vulnerabilities?

If you are looking for subjective opinion, I recommend looking through the interviews we’ve done here. At the risk of sounding like a Microsoft fan-boy, the Microsoft interviews (in my opinion) demonstrate a company where secure coding is “in the water”. Code goes through threat modeling, risky function calls have simply been banned, code goes through automated and human inspection, and vulnerabilities that do slip through feedback into the process to determine how to prevent them in the future.

I simply don’t get the same feeling from the open-source people we’ve talked to. When we’ve brought the subject up, the response is almost universally “many eyeballs,” and faith (without data) that “many eyeballs” is effective.

Am I completely off base? Do things like the Linux kernel and Apache go through rigorous security reviews? Is there proof that “many eyeballs” in open source is at least as good as something like the Security Development Lifecycle in Microsoft? If you’re in a position to know, let’s chat!

Read more

Interview With Greg Kroah-Hartman – Linux Kernel Dev/Maintainer

Posted on by Carlos Kelly

If anyone knows Linux kernel driver development, it’s Greg Kroah-Hartman, who’s been working deep in Linux for over a decade.  In this interview, Greg talks about how the Linux project has accommodated the accelerating rate of change for the kernel, and offers some insight on where Linux is headed.

Scott Swigart: Can you please introduce yourself and your association with Linux?

Greg Kroah-Hartman: Sure. I’m a Novell fellow, and I’m working on the Linux kernel with the SUSE Labs division at Novell.

I’ve been doing Linux kernel work for more than 10 years now. I’m a maintainer of several different subsystems, including USB, the driver core, and some other minor things. I’m also responsible for releasing the stable Linux kernels. I used to be a maintainer of a lot of other driver subsystems and such over the years, but I’ve thankfully handed them off to other people.

Scott: Let me start with a really big-picture question, since you’ve been involved in Linux for a long time. Obviously, there’s still lots of stuff happening on the mailing list, but fundamentally, the way code makes it into the kernel hasn’t really changed, and yet the scale of development is much larger than it was, say, five years ago.

How have you seen Linux kernel development change to handle the scale of the effort that’s going on today?

Greg: I’ve been tracking this for over five years now, and we’ve gotten a lot better. There are a lot more people doing the work.

To give an example, for the 2.5 to 2.6 kernel development series, which took about two years, the top 30 people did 80 percent of the work. Now, the top 30 people do 30 percent of the work. The sheer number of developers has also increased. We were running a couple hundred developers, and now we’re running a couple thousand.

Scott: How does that get managed? Are there more layers in the hierarchy?

Greg: We’ve invented some tools to help us out a lot. It used to be that Linus was the only one who could commit anything, or who would accept anything. It was all done through email.

And then BitKeeper was developed, and a number of us started using that. It was very nice, because we had a much faster feedback loop with Linus. I could have him pull 50 patches, see that he pulled them, and then I could hit him with another 50 patches, if I wanted to, within a day. Before, we had a lag of a couple of weeks.

Then, when we couldn’t use BitKeeper anymore, Linus wrote Git, and then that just increased it even more, because everybody can use Git. Our development model increased its capacity, and part of that was that we started trusting more people. Now we have subsystem maintainers and such.

As I said, I maintain the subsystems such as USB, and I have people who I trust enough that if they send me a patch, I’ll take it, no questions asked. Because the most important thing is I know that they will still be around in case there’s a problem with it. [laughs]

And then I send stuff off to Linus. So, Linus trusts 10 to 15 people, and I trust 10 to 15 people. And I’m one of the subsystem maintainers. So, it’s a big, giant web of trust helping this go on.

We’ve developed some procedures that help guide how and when we do merges and releases. And we’ve a very regular release schedule: every three months, we do a release. We have a two-week merge window, and all those patches in that merge window have to have been tested. We’ve gotten the development process down really well over the past four years.

We’re also increasing the rate of change in our development. The same amount of work one of the top 10 developers did last year wouldn’t have even made it into the top 20 this year. Our individual developers have got the work flow down, so we can actually contribute more, to an extent that’s amazing.

Scott: I understand that one of the things you’re involved with is the Linux Driver Project. It seems like there was a certain tension between Linux and certain hardware vendors, in the sense that, for a long time, hardware vendors had been really used to not shipping driver code.

They were used to shipping for Windows, and they didn’t have to be involved with drivers. They just provided an installer. And then, as Linux started to become a lot more popular in the server space and make some inroads in the desktop space, they wanted access to that market.

There was kind of a culture shift in a lot of companies to realize how to provide things like drivers in a way that matched with what the Linux community expected. Take the example of some hypothetical Acme hardware vendor that wants to submit a driver but has never done it before. What does the process look like?

Greg: First, people need to realize that our driver model is different than other operating systems, because all our drivers ship with the kernel. The license requires our drivers to be open, so everything is in the main kernel tree.

Because of our huge rate of change, they pretty much have to be in the kernel tree. Otherwise, keeping a driver outside the kernel is technically a very difficult thing to do, because our internal kernel APIs change very, very rapidly.

In other operating systems, APIs change more slowly, since their development process is comparatively very slow. So, it makes sense, from a technical standpoint and just to save money, to get your code into the kernel. It is maintained that way, and when changes happen within the kernel, your driver code will be fixed for you. If I have to change an API, I change it everywhere.

That approach also lets us see commonality. If see that a driver’s doing the same thing as another driver, I might merge them together in the shared core. That way, everybody benefits. The new driver gets smaller and easier to maintain.

That’s happened a lot. We’ve merged a lot of drivers from a lot of different companies, and everybody’s happy about that. The companies are happy, the users are happy with the smaller code base, and it’s easier to maintain.

The Linux Driver Project started out because of the perception that Linux doesn’t support many devices. It turns out that Linux supports all devices out there. There’s really nothing manufactured today that Linux doesn’t support, in a major consumer market. There are some one-offs, like some small video-capture devices I know of that we don’t have support for, but people are actually working on those.

The initial goal of the Linux Driver Project was to remove all barriers that could possibly be there, which were mostly managerial. To attain that goal, we said that we will write and maintain any driver for free for any company.

It turned out that not very many companies really needed that. A few niche markets needed it, and we’re writing some drivers for them, but most companies had existing drivers floating around inside their company. Their challenge was typically that they needed to get it into the kernel tree, and they didn’t know how.

So, the Linux Driver Project, over the past couple years, has just been a big educational thing. I work with the companies and show them how to get the code in. I maintain the code, massage it and get it cleaned up, and then merge it into the kernel tree. That’s been the majority of the work we’ve been doing over the past two years.

We’ve also now codified a few ways that we can play in the kernel. We can accept code into the kernel that doesn’t meet our normal standards into a staging area. Everybody can clean it up there, and then the code graduates into the real stuff. That’s worked out really well.

Scott: That makes good sense, because someone coming in from the outside isn’t necessarily going to know everything from coding standards to the best practices for doing things the right way.

And so what you’re saying is that you’ve got a place to get that code in, where people who know the right way to do things can look for things that can be factored out of drivers, drivers that can be merged, and that kind of stuff.

It doesn’t force every hardware vendor or everybody who needs to get a driver into the kernel to be a Linux driver development expert. Do I have that right?

Greg: Yeah, although we do have lots of documentation now. We have free books on how to write Linux drivers, and we have documentation of things like our coding style and how to submit code. If people don’t know where it is, we’ll point them in the right direction. In case anyone’s curious, it all starts in a file called HOWTO in the kernel, so they can start there.

Even though we do have those education tools, though, we will also work with companies that want it. We have lots of people who have done this work before and who will do it for you.

It’s a great place for people wanting to get involved in the kernel to start out, because they can just run a script to find some errors and go fix them. We have people that have started off just wanting to get involved who have ended up maintaining whole drivers and subsystems over time.

Still, in the end, my goal is actually to work with engineers from those companies and have them maintain and own it, so they become full-fledged members of the kernel community. That’s the only way we’re going to grow, and it’s working. The number of companies involved in the kernel has grown year over year.

Companies want to get the most value out of Linux, so I counsel them that they should drive the development of their driver and of Linux as a whole in the direction that they think makes the most sense. If they rely on Linux and feel that Linux is going to be part of their business, I think they should become involved so they can help change it for the better.

Scott: That makes sense. In a different area, I saw somewhere that around half of the Linux code that’s being contributed nowadays is driver code. Do I have that right?

Greg: That’s the percentage. Like I said, everything’s in the kernel itself. We’re at something like six or seven million lines of code, and over 50 percent of those lines of code are drivers.

I think 30 percent is architecture-specific stuff, for things like processors and networking. The core kernel is like five percent of the overall code. Those numbers have stayed pretty much the same over the past four or five years.

We change something like 5,000 lines a day, which is just scary. Fifty percent of that change will be in the drivers, and five percent will be in the core kernel. In other words, the kernel is being modified everywhere at that rate of change.

Scott: Do I understand correctly that the core kernel is memory management, process scheduling, and those kinds of fundamental things that an OS has to do?

Greg: Exactly. Basic system calls, memory management, scheduling, and inter-process communications.

And the only reason we’re changing is because people want that change. It’s not like we’re sitting there and

Read more

Interview With Matt Gibbs – Development Manager – UI Framework And Services – Microsoft

Posted on by Carlos Kelly

In this interview with Matt, we asked him about:

 

Scott Swigart: Hi, Matt. Before we start, go ahead and introduce yourself.

Matt:I’m Matt Gibbs, and I’m the Development Manager in the UI Framework and Services at Microsoft. My team is responsible for ASP.NET and AJAX as well as parts of Silverlight.

Scott Swigart: Thanks! We’ve been commissioned to look into the premise that open source and closed source SDLs [Software Development Lifecycles] are fundamentally different, and that the differences manifest themselves in the final products in tangible ways.

That’s not to say that one is better than the other – certainly both models have their strengths and weaknesses – but it’s really designed to get information out there for two audiences: one is software vendors who are looking at building products. One of their first choices is whether they are going to go with an open source or a closed source model, and we want to look at some of the ramifications of that choice.

The second audience is people bringing products into their organizations, and we want to uncover some of the basic expectations that they could have around open and closed source, or some of the characteristics of each model that might impact their choices.

Richard Bowler: You’ve been the Development Manager for ASP.NET for about a year, right?

Matt: Yes, about a year.

Richard: What would you say are the major development challenges with that product?

Matt: I think for us, the biggest challenge is that we have a large customer base, so as we innovate, we have to be very sensitive to backwards compatibility. We have a fairly complex platform, so innovation is challenging when you’re trying to make sure that existing applications people have built with it continue working.

Richard: It’s a pretty complex project, and it’s built on another complex project, which is the CLR; to co-develop with the CLR team, do you just take what they give you and work from there, or how does that work?

Matt: We work really closely with them. In fact, we meet regularly to go through code changes we’re making with members of the CLR team, so that we’re all in sync.

Richard: It sounds like you’ve been able to direct feedback to them, saying, “We really need this kind of capability, let’s fold it into the next release,” or something like that.

Matt: Yes. And they’re pretty sensitive to how their changes impact us. They run compatibility tests and stress tests against our scenarios, as well.

Richard: It seems like a huge challenge, when you consider the number of software products that Microsoft has on the market that interoperate. It seems like a huge challenge to keep them all working together.

Matt: For the framework we’ve actually held a pretty strict line. I am part of a committee where we review things that were classified as “potentially breaking a developer’s code,” and the default was that those weren’t allowed – that was kind of the highest priority. Things like “security fixes” would be allowed. Then there always needs to be a way to get back to an earlier version’s behavior, through a configuration parameter, for example.

Richard: Speaking about security, we talked with Michael Howard, and also with James Whittaker about the SDL. It looks like it’s really paying off for you guys. Were you involved in the development internally when the SDL was being instituted at Microsoft?

Matt: Yes, actually I worked with Michael Howard on IIS where we ran into a few security issues that helped highlight the need for a more structured approach.

Richard: I know what the benefits are, because we discussed it with Michael and James. But what were the main difficulties in shoehorning those new processes over the top of existing SDL processes?

Matt: I don’t think it really came down to process difficulties, as much as it came down to just helping developers recognize that the mindset they had been using needed to be front-loaded with security all along.
In our first round, everybody recognized that we needed to pay even more attention to security, and make it a higher priority. But then the realization was that it can’t be one phase in the development process. It really needs to be something that we pay attention to all along.

Richard: To put it another way, then, you had to get a wrench on the culture. You had to make security important in everyone’s mind.

Matt: Right, and it really had to be the case that everybody came to the same conclusion. You couldn’t just tell people it was important – they had to see what kind of impact it had to customers, and recognize it themselves.

Richard: Did you get much internal resistance from individual developers, or was there pretty much across-the-board buy-in?

Matt: It was pretty wholesale – everyone recognized it. I think particularly since I’ve been involved in web platforms, and we saw a couple of places where we’ve made mistakes, everybody recognized, “OK, we have to do something different, and be more practiced in this,” because otherwise we’re not going to get the right outcome.

Richard: Where was ASP.NET in the process of instituting the SDL? Was Version 1 out before the SDL really came to the fore?

Matt: No, when the process was launched we were already in development. It was during that cycle where we decided to take a break, and we went back and said, “We need to invest time in this process.” Everybody did some extra security training, and then we essentially stopped development, and did a pass for just security. We looked at every feature, all the code, looking for specific issues, just to make sure we had done all the right things.

Scott: One of the things that I found looking at the open source side of things, is just the sheer number of distributions that they have to ship for a product. MySQL for example, I think has 16 distributions, because it has to run on all of these different flavors of Linux, none of which the people working on MySQL really have a lot of control over. Those versions of Linux are all rev’ing independently of each other, so the underlying operating system that it’s dependent on is changing all the time. You’ve got a whole ton of applications that are built on top of MySQL, and are therefore dependent on it.

I can’t even really imagine exactly how to test that, and I know that in the open source world there are issues about, “This version of MySQL isn’t compatible with this version of WordPress, which isn’t compatible with this version of Linux.” So, they are always fighting these compatibility issues as things just rev independently of each other all the time.

Microsoft has some rather similar challenges, in the sense that IIS revs with the server. ASP.NET revs on its own timeline, which isn’t tied to the base operating system, and Atlas is also on its own timeline to some degree.

Talk a little bit about the kind of test matrices that Microsoft builds, and the amount of resources in terms of hardware and testers that come to bear when you guys are getting ready to release something, or while you’re developing something to ensure compatibility with all the versions of all the things you ship.

Matt: It’s probably more expensive than you might initially think, because in the same way that there are a bunch of different Linux distributions, we also still test against a lot of different supported versions of the operating system.

We’ll test against XP and Windows 2000 and Win2k3, with different levels of the service packs and with components installed; with Visual Studio installed, without Visual Studio installed, and then different flavors of IIS. We’re already testing with IIS 7 on Vista where we’ve got a lot of integration work going on. When we go to do compatibility checking and functional testing, we have a fairly large lab. And the run time, unfortunately, is on the order of weeks to really ensure compatibility.

Scott: What I’m envisioning is that somebody pushes a big button, and a hundred machines get configured with tests. It all comes up and runs, and results get cranked out — test, pass, or fail. Is it something kind of like that?

Matt: Yes, and they categorize tests into different levels of priorities so they can say, “We’re going to do a quick sanity check on something,” and that can take a couple of days. Or, they can say, “We want to run the gauntlet, and run everything we’ve got,” like before a service pack or something, and that will take much longer.
It covers everything from different language packs, to different service packs installed. One time-consuming thing is that errors that are false positives come up, and they need to be investigated. These might be just test issues, and that takes time as well, because you don’t want to ship with something that might be a problem, so everything has to be investigated.

Scott: I know that Microsoft’s got certain terminology around this. I’ve heard of something called the BVT, which I think stands for Build Verification Test. There are things that have to happen before something gets released as a CTP, Community Tech Preview. Can you talk a little bit about that, in terms of what the different levels of testing are, and what kind of things have to get verified on those different levels?

Matt: There’s a scaled approach. On a developer’s machine, we’ll have what we typically call Developer Tests.
The developer cranks out a lot of small standalone tests against the feature he’s building, against his APIs. He’ll run those every time he goes to check in code. We’ll aggregate those for our dev team, so that you’re running a fairly lengthy set of them. But, they still run within just a few minutes, so that you can continue making fast development progress. Then we’ll run a superset of those before we check in.

Scott: So, that’s to make sure that one developer’s change didn’t break some other developer’s code.

Matt: Yeah, that the basic functionality is intact. Then, the test team runs what they call a set of nightlies. They’ll run those on every daily build that comes out, they’ll kick off an automated set of nigthlies. They’re small enough in scope that they can run overnight, and any failures can be investigated fairly quickly. They are what they call “Pri0” test cases; and that would be mainstream use-cases.
Then, the superset of that is something that’s maybe ten times the number of test cases, and that’ll run for days to verify the full functionality. That’s literally thousands upon thousands of test cases.

Richard: So, your nightlies maintain a level of sanity about the ongoing nature of the code base – yesterday it was still good, today it’s still good, tomorrow somebody’s checking in something bad. Let’s back up and fix this so you never get too far out of whack.

Matt: Then, you may find something when you go through a full test pass. When the tester originally made the test plan, they may have said it’s a fringe scenario, so it was classified as a priority two test case. You might only run it before a release, and then something breaks.

Scott: Microsoft has a lot of people who blog, so there are obviously a lot of people on the product teams who are fairly transparent about where they are and what they’re doing. I think Scott Guthrie put up a big blog post where

Read more

Interview With Rod Johnson – CEO – Interface21

Posted on by Carlos Kelly

In this interview with Rod, CEO of Interface 21 and founder of the Spring framework, we asked him about:

Scott Swigart: Rod, thanks for taking the time to chat. If you don’t mind, please take a moment to introduce yourself.

Rod Johnson: I am the founder of the Spring Framework, which has become the effective standard for enterprise Java development. We also have a spring.net edition. I am CEO of Interface 21, which is the company behind Spring. I’m also the author of several books on J2EE development.

Scott: Great! Talk to me a little bit about the development methodology of the Spring framework. How does that work? Every open-source project seems to have its flavor. Tell me how Spring is built. How do ideas go from conception to features to in production or in development to release?

Rod: OK. I think when people try to understand what open source is, they instantly think about code and that the software is created by a disparate, far-flung group of people who work in their spare time. In fact, to understand the open-source model you need to step back from code and look at the totality of things, which includes documentation, includes support for users, and includes the discussion of ideas.

What we see in the core of our software is that the vast majority of the code is written by a small group of exceptionally good people. I don’t believe there is any other way to produce exceptionally good software. We have known for many years about what Fred Brooks calls the The Mythical Man-Month.

Scott: Right.

Rod: Open source doesn’t change that. We know that if you throw more people at a problem you don’t get a better solution. And it doesn’t matter what approach to distributing the source of the software you use. You’re not going to change that fundamental fact. If you want exceptionally good software, you want a cohesive team of exceptionally good people and you really want that team to be as small as possible.

Scott: How is that team motivated to work on the project?

Rod: The core people who connect to Spring daily are employees. They are being paid to do this. That model works very, very well if you look at open source in terms of the enterprise Java space and also obviously of the Linux space. You see that the model is evolving towards paying the contributors who write the code. For example, I think 21 out of the top 25 committers on Linux are employees of large corporations. The majority of the committers on Spring are Interface 21 employees. Another good example of this is JBoss, the Java application server. The majority of the code there comes from employees of JBoss, who are now employees of Red Hat.

Scott: I want to get your insight on the Linux kernel. My understanding of the Linux kernel is that unless Linus likes a certain patch, it’s not going to make it into the kernel. And yet, the bulk of the development is done by people who work for IBM, people who work for Red Hat, Intel, AMD, whoever. Right? Corporations are doing the bulk of the work. And yet what makes it in or out of the kernel isn’t really under the control of a company. Do you have any insight into how that works?

Rod: I am not an expert on Linux kernel governance. From what I see, one thing that is very, very important to developing high quality software and maintaining that software in high quality for the long-term is consequences: consequences of success, consequences of screwing up.

In the case of Linux, what we have is not a single entity, but we have a number of companies (and in Linus’ case partly also an individual, obviously) and a number of parties that are really baked into the system because there are large consequences if they screw up.

I don’t think one entity needs to be responsible for a piece of software. I think you can end up with a kind of partnership, but there have to be consequences if something is screwed up. That is one thing that scares me about the rather naive volunteerism view of open source because what are the consequences to a volunteer? Sure, in many cases they may be professionals. They may feel as a sense of personal ownership that they cannot be satisfied unless something is as good as it possibly can be. But there ultimately are problems because they don’t necessarily suffer the same kind of consequences if something isn’t taken forward.

Scott: What people have told me is that there is sort of a developer Darwinism that happens. In other words, to get your code in you have to submit it to a mailing list. You have to submit it to what one person described as a “full contact code review” and in some mailing lists you’ll just simply flat out get ridiculed and won’t be taken seriously if your code isn’t to a certain level. So, it seems reputation based, I guess. You can’t really get code in until it’s passed code review and up the chain of maintainers. So, on one hand there isn’t a lot of consequence to writing bad code, except maybe it was a complete waste of time. Your inability to do it well was pointed out for the whole world to see. So, it seems there is a certain amount of pressure to sit up straight and code well, especially if you’re going to try to get stuff into very high profile, very core open-source products like the Apache, or Linux, or some things like that.

Rod: Yeah.

Scott: One of the things that you pointed out is that people who are going to use open source shouldn’t consider it a free ride. It isn’t just something that you should just leech off if you want the stuff that you’re dependent on to continue to thrive, grow, and be there for you, and continue to be enhanced down the road.

But, at the same time, most of the core contributors to open-source products are highly skilled people who are employed by a company, and this is what they do all day long. So, if I’m going to be a user of open source, how could I best contribute?

Rod: The first thing is that I would hate to give the impression that openness means nothing. There is one interesting characteristic, for example, about a piece of software like Spring, which is overwhelmingly written by one company, compared to closed source.

You have the ability to work up to being a committer of the software. Not many people will take that up. And we may choose to approach you to see if we can hire you if you do it. And that is a way of expanding and renewing the developer base.

So, it is open in the sense that there is opportunity for people to come to be committers on the software through the community based on merit. That is interesting because if I want to be a contributor on the Java-based IBM’s WebSphere, I’m sure I could add some value based on my background to WebSphere, but I can’t put my code in there. There is no way I can do it without becoming an IBM employee.

Scott: Right.

Rod: So that is a genuine difference. There is a true meritocracy. So, coming back to your question, which was “How do you pay? How do you contribute back?”

Scott: Yeah, how do you contribute?

Rod: Well, I think the first thing is to remember that although it’s very important that there is that meritocracy based on code there are several reasons that the majority of users are never going to contribute to that code. The majority of users are not going to modify and compile it. The majority of users are going to use it essentially as if it’s a shrink-wrap product.

I make all of our consultants just use the binaries. If they’re working with our product with customers, we don’t like them to be working with the source code and making changes to the source code of our product.

The interesting thing is that it simulates more accurately how end users use it. So, often we’ll go into customers where we’ll see that they just realized that you can mount the source code and if you want to step through the same work source code…

Scott: Right.

Rod: …so, it just doesn’t make sense for most end users to even consider modifying the software. Consider that Spring is 1.2 million lines of code. Some of that code does things like transaction management, the fundamental configuration of your application. Some of it executes in virtually every runtime call set. It doesn’t matter whether its open source or closed source, you really don’t mess with code that does that kind of thing unless you know what you’re doing.

Scott: Right.

Rod: The process of knowing what you’re doing…For example, in our transaction infrastructure I, myself, as the original co-designer, made a change about a year ago. I spent almost a day conceptualizing the current state of the code (which one of our other guys had modified) and figuring out exactly how I could do these [changes] in a safe way.

I am a strong enterprise Java developer with 10 years experience. I originally co-designed this module so I know how it is meant to work, yet it still took me almost a day to feel that I can safely make a change without risking breakage of a core part of the software.

Imagine if I were someone coming from outside who didn’t have 10 years of experience, hadn’t co-designed the module. What is the probability that I’m going to make that change in a robust way unless I spend maybe five days fully getting inside it?

Now, if I am an end user and I am writing software, for example for a bank, like many of our users, they don’t want to pay me for five days to figure out how the Spring framework works internally. That is irrational. There is little economic benefit for end users. There is a high probability of being economically irrational in modifying the open source software.

Another good example is Linux. I did a lot of C-programming early in my career. I can code in C. Am I ever going to look inside the kernel and change any of the kernel? This makes no sense, whatsoever. So, code contributions and changes are not likely. However, there are many other things I can do if I wish to give something back.

One thing I can do is to help other users of the software. Most open source projects have forums and mailing lists. Every time a developer answers a question for a user that developer is distracted and can’t write code to improve the product. Both things are important but no one can do both simultaneously.

One thing that has worked brilliantly with Spring is, especially early on, we made a big effort in the core development team to answer users’ questions and be really, really helpful. That set up a virtual circle, where users saw the Spring development team was really helpful when they were first starting up. Gradually they used the software more and became experienced. Then, they see other people asking questions and they think, “Hey I know the answer to that question. Maybe Ron doesn’t have to spend time answering that question. I’ll get in there and I’ll help the other user.” That’s a valuable way of giving back.

Another

Read more