2015-06-19T12:44:57-07:00At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source... At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source license. That's all really. Indeed, the last paragraph of Klint Finley's (@klintron) otherwise excellent article gets it wrong when it says, "But by moving programming languages and other core developer technology into the realm of open source, companies like Apple can provide some assurances that developers will be able to adopt these tools to their own needs without facing legal action." Not even a little bit true. The risks are all still there. Another company could still happily sue the living daylights out of anyone they believe to be infringing their property. And it's not simply the community and legal basics people continue to misunderstand. There's still a surprising lack of understanding in companies big and small about the business and economic basics. John Mark Walker (@johnmark) recently completed a brilliant four-part series of posts outlining the basic "how to make money" with open source. The opening paragraph to the series begins: "I never thought I’d have to write this article in 2015. By now, I thought it would be self-evident how to derive revenue from open source software platforms. But alas, no. Despite the fact that the success of open source software is unparalleled and dominates the global software industry, there are still far too many startups repeating the same mistakes from a thousand startups past. And there are still far too many larger companies that simply don't understand what it means to participate in, much less lead, an open source community." I encourage you to find time to read all four posts . While John Mark presently works at Red Hat, a company that deeply understands the business of open source, his experience goes back almost 20 years to when he worked at VA Linux. Companies are indeed contributing more and more to software licensed as open source. Google is building a community around Go and last year began a community around Kubernetes. Go is certainly an interesting language growing in popularity, but Kubernetes represents a decade of Google research and experience in deploying, managing and orchestrating application containers at a time when the industry at large is just catching up. Apple will launch Swift into the public eye. Even Microsoft has learned that they must engage differently with developers and has published .NET (for the second time) late last year. It is no longer about broadcast communities like MSDN. Building community is where the work gets done for a company sharing assets and collaborating around software, and building community is hard work. There are lessons for Apple to learn and quickly. To build a community, it has to be blindingly easy to engage. The software needs to download and build to a known tested state on a known platform (ideally many) if you want developers to spend time. Otherwise your project becomes one more moribund collection of software thrown over the wall onto github or SourceForge that will frustrate developers and finally chase them away. There are a well known set of patterns and practices that work to enable and build successful communities. This isn't a secret. And early communities are skittish fragile things. I was part of the original publishing of .NET under an academic research license. There are lessons here for Apple in how to get it "right". We published roughly a million lines of code for the C# compiler, Base Class libraries, and Common Language Run-time (and a complete platform abstraction layer, and a full test harness). Once a developer unpacked the source archive, it was a two [simple] line sequenc[...]
2015-03-18T16:20:35-07:00The Openstack project feels different from other open source projects to me. Let me try to explain. Henrik Ingo did an excellent analysis of open source project size versus governance structure a few years ago. Essentially, the nine largest most... The Openstack project feels different from other open source projects to me. Let me try to explain. Henrik Ingo did an excellent analysis of open source project size versus governance structure a few years ago. Essentially, the nine largest most vibrant open source communities were anchored inside non-profit foundations. The tenth largest was an order of magnitude smaller and existed inside a corporation. Henrik was a good engineer and provided his data and listed his assumptions. He was not suggesting that the growth was causal, simply that there was a strong correlation. He rightly observed that it will be fascinating to see what it all means using Openstack as an example when he presented his findings Summer 2011. (He wrote an excellent follow-up post comparing cloud projects later.) Henrik’s analysis and observations presumes certain criteria about how the open source licensed project must be functioning in and of itself. It has to be a “well run project” before getting to the foundation amplifier. Lots of people have described essentials of successful communities. Some of my favorites include Dave Neary, Donny Berholz, and Kohsuke Kawaguchi, and of course there’s Jono Bacon’s essential reference. I tried to capture and collect together the patterns and practices of successful open source projects in a blog post a while ago. Paula Hunter and I offered rationale for the foundation amplification when we were executive and technical directors at the Outercurve Foundation. What might be the cause of the amplification? We believe it comes from the one thing ALL foundations do for their stakeholders around their projects. Foundations exist at the behest of their stakeholders to make clear the IP management requirements and provide IP risk mitigation. The project community must be well run from engineering and governance perspectives, but once a foundation exists, corporate participants have a clear on ramp for participation and the investment in the community can grow substantially. So Solid Engineering Practices + Strong Community Governance + Clear IP Management enables Growth. So far so good. But Openstack is somewhat unique as an open source project. It was 2010. Amazon had enormous early mover momentum in providing cloud services . Eucalyptus was open source-licensed but controlled by a single vendor (née 2009). Cloudstack was just published under an open source license [May 2010] but still closely held by Cloud.com. The time was ripe for a vendor neutral option. Openstack was announced into existence by then Rackspace CEO, Lew Moorman, and NASA CTO, Chris Kemp, at OSCON 2010. A large collection of vendors jumped early and hard onto a simple infrastructure to evolve it rapidly forward into a marketplace of potential customers. The project governance was created and people started gathering at summits. Openstack was correctly forced into a neutral, non-profit foundation within two years to clarify IP ownership. (Everyone had MySQL as an example on their mind, as it had been bought by Sun Microsystems , and then bought and ransomed by Oracle .) But here’s where Openstack begins to break patterns. There was relatively little code at the start. It was created from the start to engineer forward. Openstack is going through forced growth in a time frame that is a 20%-25% of the time of other large-scale successful open source-licensed infrastructure projects. Instead of 20 years, the effort is becoming enormous in four, already driving serious vendor-lead products to market. ProjectStarted (age)LoC Mid-point**LoC TodayContributors Mid-pointContributorsTodayRe-ArchFoundation Linux kernel 1991 (23) 4,000,000 17,000,000 186 1000 2002 2000 Apache (httpd) 1995 (19) 980,000 1,700,000 17 1[...]
2015-03-06T00:31:57-08:00Jim Zemlin has always been quotable. His keynote at this year’s Linux Collaboration Summit provided a great summary (as always) of the growth of the Linux ecosystem, but also focused on the serious problems in the security of the Internet... Jim Zemlin has always been quotable. His keynote at this year’s Linux Collaboration Summit provided a great summary (as always) of the growth of the Linux ecosystem, but also focused on the serious problems in the security of the Internet in an era when key breaches have their own branding and logos. [Think Heartbleed and Shellshock.] He ran through some scary facts: OpenSSL secures most of the Internet and the small team at the OpenSSL Foundation (including the “two Steves”, Steve Henson and Steve Marquess) were only pulling in about US$2000 in donations per year. Theo de Raadt supports OpenSSH part-time. Harlan Stenn “runs the clocks on the Internet”, i.e. he’s responsible for ntpd, and until recently was earning about US$25K/year. Werner Koch maintains GnuPG, which secures a lot of email and provides the confirmation that a software package is what it says it is. According to a recent interview, he was going broke. Before readers unversed in open source software get concerned with the security of open source software, let us remember this is a software problem, not an open source problem. Closed proprietary products have their share of exploits, etc. But with open source licensed software, the broad community can do things. It is perplexing that if Linus’s Law is true, “Given enough eyeballs, all bugs are shallow", then such security problems persist. Jim suggested as he gave the above examples that “there just aren’t enough eyes.” I’d offer a corollary. I think vibrant projects live a culture of review before code gets committed. I think this is because the developers have perspective and context that can never be built into a static analysis tool. Tools can find obvious portability breakage, or some security related issues (e.g. buffer overflow problems), so issues that are likely syntactically based, but a human can understand the semantic content of the code in front of them. There's even research to back this up: Walcélio Melo, Forrest Shull, Guilherme Horta Travassos, "Software Review Guidelines", Technical Report ES 556/01, COPPE/UFRJ, August 2001. "Code review is more effective than test because in review the faults in the code are found directly, while testing uncovers only the symptoms of problems, requiring debugging to find the direct cause. The seriousness of the wrong behavior by the system does not have a relation to the type of mistake, since even simple mistakes can cause complex behaviors." Reidar Conradi, Amarjit Singh Marjara, Øivind Hantho, Torbjørn Frotveit, and Børge Skåtevik, "A Study of Inspections and Testing at Ericsson, NO", a rewritten edition of the paper presented at PROFES'99 (Oulu, Finland, June 1999). From the Conclusion: "Software inspections are indeed cost-effective: They find about 70% of the recorded defects, take 6% to 9% of the development effort, and yield an estimated saving of 21% to 34%. i.e., finding and correcting defects before testing pays off, so indeed “quality is free”.” and: "Individual inspection reading and individual Code Reviews are the most cost-effective techniques to detect defects, while System Tests are the least cost-effective." In the open source community bugs are found quickly, but this happens after the fact. Vibrant projects live a culture of review before code gets committed so it’s much more like they find the bugs before they happen. Many of the key projects that have had breaches are taken for granted and don’t necessarily have the vibrancy of a Linux, or an Openstack. These projects have simply become part of the fabric of the Internet. The Linux Foundation is stepping up to tackle these problems with the Core Infrastructure Initiative (CII). The Foundation is in an exce[...]
2015-03-02T12:00:22-08:00I attended the Linux Collaboration Summit last week. There was a kick-off panel on the opening day (http://sched.co/28x6) and then a couple of days of working group style presentations around OPNFV. The work comes under the sponsorship of the Linux... I attended the Linux Collaboration Summit last week. There was a kick-off panel on the opening day (http://sched.co/28x6) and then a couple of days of working group style presentations around OPNFV. The work comes under the sponsorship of the Linux Foundation and hopes to establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of Network Function Virtualization. (Or read here for the ETSI definition of NFV). There’s a really good description of the intended work and architecture on the OPNFV site. The panel was moderated by OpenDaylight exec director Neela Jacques, and participants included Eriksson, Red Hat, Cumulus Networks, and the community manager from Openstack. I tracked the OPNFV work for its first half day of the follow-on workshop and spot checked the work for much of a second day. OPNFV started last Autumn. To develop a "reference platform" for NFV activities, the group wants to integrate the work across other open source projects (OpenDaylight, OpenVSwitch, Openstack, etc.), determining what is needed and working with the relevant upstream groups to contribute to each project community appropriately. What’s most interesting to me is the very different cultures that are exposed in the room. Successful open source communities: build the one true implementation by collaborating through contributions upstream, and meritocratic influence is driven by the contribution of code, infrastructure, and effort. Standards organizations on the other hand : collaborate on interface specifications to enable multiple [communicating] implementations by negotiating a compromise position amongst participants, and democratic influence is gained by diplomacy and participation. Time frames are also different very different between such technical collaborations. Successful open source communities are building in real time, and larger complex projects have begun scheduling themselves around agile six month delivery cycles. Standards documents often need to support complex externally driven procurement and certification needs and are carefully [sometimes deliberately slowly] developed to ensure participants can meet those needs, and once agreed, change relatively carefully i.e. slowly and with rightly conservative process. (For the moment we’ll assume the open source project is mature enough to be hosted inside a foundation so IP management is understood, and that the IP management of the standard is equally well managed in the standards development organization.) NFV is a telecommunications thing and the telco world was historically driven by standards with large internationally-focused organizations (ISO/IEC, ETSI, etc.) at their core. Linux as a vibrant open source community has demonstrated its ability to deliver vendor-collaborative engineering value this past 25 years. Openstack is attempting to replicate that success and is the hub for much of the present Infrastructure-as-a-Service (IaaS) cloud work. As explorations of software defined networking (SDN) have begun in the open source community, projects such as OpenDaylight (also under the auspices of the Linux Foundation) and now OPNFV have begun. The telco community wants to invest in driving this sort of open source collaborative work forward to reap the benefits of reduced costs and delivery agility. They just don't necessarily know they need to participate differently. The OPNFV working group provided a stark example of this lack of understanding. Dave Neary (Red Hat) gave an excellent presentation on open source collaboration to the room. Chris Wright (also Red Hat) led a number of discussions. But many of the comments from the [...]
2013-08-20T13:18:00-07:00I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in... I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in the past with a few new essays. One of the last topics I wanted to tackle is the question of when not to publish software under FOSS licensing terms from the perspective of companies in a position to "make" FOSS software. Many managers are concerned with creating and contributing to the open source ecosystem for two primary reasons: Losing control of the “value” inherent in the IP creation, and the liability risks of contributing to or publishing the software. If liability risk is the real problem, then one needs to be sure that one is comfortable with the FOSS license terms, any terms of service that may be involved in the project’s web presence, and the IP management process in place to vet contributions, regardless of whether one is accepting inbound contributions to one's own FOSS-licensed project or outwardly contributing to another project. There’s not much more that can be done about such perceived risk. A company will either be comfortable with the benefits against the risk analysis or not. A good measure of the risk however is the number of lawsuits that have happened in the open source space relating to copyright. The few that exist tend to be focused on a company using open source software in their products and services while blatantly ignoring the FOSS licensing terms. Openly and honestly participating in an open source community doesn’t appear to lead to lawsuits. Liability risk is probably not a good reason NOT to make FOSS software unless you have a particular risk profile. The value of the software published is a very different discussion. People need to be very crisp when discussing value. One should never publish one’s core value proposition to its customers. Geoffrey Moore published “Crossing the Chasm” in 1991, and helped business managers understand the concept of their core value proposition. This was a very customer-focused “core” value. Everything else was a complement around the core. It related to the problem one solved for the customer. In later writings (“Dealing with Darwin”) Moore once again discussed core value, but here he was discussing core competency. It was an inward focused core value, and everything else a company did was context. It wasn’t what the customer bought, but rather how one solved the customer's problem. Core competencies and core value propositions shouldn’t be published for all to use. If the software you have represents the core competency of the company, or generates a substantial competitive edge, it shouldn’t be shared under liberal licenses. The trick, however, is in understanding the truth about the core competency. Google is an excellent example of this idea. Google consumes a lot of open source, and contributes back in a myriad of ways. But it hasn’t historically shared certain changes it has made to the Linux kernel, nor does it publish all the tools it uses to rapidly deliver software to customers. Red Hat is another more interesting example. One could argue they simply publish a Linux distribution. The reality is that they dominate the space because they understand it isn’t the software asset that the customer is buying (and over which Red Hat has no particular ownership or control) but all the value around the software in services and risk mitigation and quality and ease-of-deployment that made Red Hat Enterprise Linux such a great replacement for expensive proprietary UNIX systems, and now an excellent server platform going forwa[...]
2013-07-16T16:32:46-07:00How do you create a successful free or open source software project? There are two parts to “success”: Deployment growth: One publishes software to see it used. Even from the minimalist view point of, “It was useful to me; it... How do you create a successful free or open source software project? There are two parts to “success”: Deployment growth: One publishes software to see it used. Even from the minimalist view point of, “It was useful to me; it might be useful to you.” But as the software is used, it reflects the dynamic nature of software, and as a solution to a problem, it gets used in new ways to solve new problems. This leads to the second part of the success formula -- contributions. Contribution flow: A free or open source software project is at it’s simplest a discussion in software, and without contributions the conversation fades and fails. From a more complex community perspective, a FOSS project is about the economics of collaborative innovation and development. Without a continuous contribution flow, the dynamic aspect of a software project will become static and brittle and lose its relevancy. As the software at the core of the project is the dynamic thing (the “meme” to replicate), we need developers capable of contributing to the project. Developers that might contribute are people that probably started as users of the software project. They found the software, used it, perhaps fixed a bug, perhaps added a feature, or repurposed the software to a new problem. At this point they are in a position to contribute, but there’s work to be done to encourage and allow that contribution. So there are three onramps that a FOSS project’s committer(s) need to build and relentlessly improve: Attract lots of users: The software needs to be easy to install/configure/use (and this applies to developer tools, libraries, and frameworks as much as to user space apps and tools). Out of this user base, attract developers: The software needs to be easy to download, and build and test to a known state. This allows potential developers to experiment/fix/extend the software project FOR THEMSELVES and their own selfish needs. Out of this pool of developers, attract contributors because there's actually a well thought out pipeline and communications about what, where, and how to contribute. Contributions DO come from users, for example bug reports. But a project still needs to communicate with users to enable them to contribute good bug reports. We have seen these pipelines anecdotally for years. In the early days of PC-based software (in the early '90s) there was the 5-Minute Rule (or 10-Minute Rule depending on who you consulted) that said if the software didn't install and do something useful [very] quickly it became shelfware. Today, how many people download an open source project and never get it working and walk away? How much time are you willing to invest installing, configuring, building, testing, working through the forums, before you declare defeat and move on. How many potential contributors do you leave feeling frustrated and stupid? There was an idea expressed by core committers in some open source communities 10-15 years ago that said it's orders of magnitude between communities and contributions, i.e. for every 1000 users, you might see 100 bug reports, out of which 10 will send code that purports to fix said bug, out of which 1 read your coding guidelines and really did fix the bug. I heard this from a couple of communities (BIG = sendmail, small = graphics drivers) and have "tested" the statement on many core committers since who all stop, think, and agree. (Caveat lector: This is purely anecdotal. I’m thinking about ways to hunt through the data streams for proof along the lines of Donnie Berkholz’s excellent recent investigation.) We see it in statements in their talks from the likes of Jono Bacon ("We [...]
2013-07-09T10:12:24-07:00I’ve not written one of these posts for some time. I left the Outercurve Foundation effective the beginning of July. The Outercurve Foundation is in the process of restructuring its services and membership structure to meet a broader audience of...I’ve not written one of these posts for some time. I left the Outercurve Foundation effective the beginning of July. The Outercurve Foundation is in the process of restructuring its services and membership structure to meet a broader audience of developers and to deliver hopefully more value to its existing projects. (Stay tuned for announcements in that space.) Part of this effort will require an increased focus on technology to facilitate more automated services, rather than "staff intensive" services. To that end, I have left as Outercurve’s Technical Director. It has been a great three years. The technical non-profit consortia of my experience were all launched with a collection of a dozen CEOs on stage explaining to customers the strategic significance of the collaboration to their businesses. This anchors the initial membership and acts as the inbound vector for new sponsors and members. The Outercurve Foundation (originally called the Codeplex Foundation) launched differently. Outercurve has always had much more of a start-up feel to it. The interim board hired Paula Hunter as executive director in Feb 2010, who then hired me in May of 2010. Paula and I defined a business model for our “start-up”, iterating over the value foundations provide their free and open source software projects, and why they’re important for the growth of their projects. A lot of the thinking has gone into the various presentations we’ve given, and culminated in the recently published International FOSS Law Review article. It’s been interesting to define the Outercurve business against the other key foundations as they each evolved around their key projects. Foundations provide IP management, a neutral non-profit space for projects to grow as commercial interest in participation grows, and experience to guide new projects. We worked at Outercurve to define a light weight IP policy while remaining rigorous. Likewise, we developed a mentorship program instead of insisting projects survive an incubation process. Our efforts at education have grown to include hosting the first modest conference for our projects with an agenda that included the likes of Jono Bacon, Scott Guthrie, Donnie Berkholz, Ross Gardler, Kohsuke Kawaguchi, and several of our more experienced project leaders. Outercurve has grown to 28+ projects, with hundreds of contributors, and millions of lines of code across three gallery “collections”, with shining stars in each gallery. Website Panel, Chronozoom, Orchard, and NuGet continue to grow and thrive. (NuGet is now embedded in Visual Studio demonstrating that even Microsoft product teams are fully taking onboard how to live in a co-joined open source-enabled proprietary product world.) There are more, varied and interesting projects in the pipeline in discussions with the Foundation. Working with Paula has been a pleasure. I’ve learned an enormous amount about non-profits as businesses, and the start-up as non-profit. She remains the Operational Goddess. I’ve also had the privilege of making many new acquaintances and friends this past three years. But the Board is shifting its business model evolution, it’s a new fiscal year at the Foundation, and it’s time for me to move on. There are a couple of projects I’m chasing presently. At the Outercurve Open Source Software Conference I presented the start of work on patterns and practices for open source success [slides, video]. I believe there are certain activities that software development teams do that allow them to scale successfully, regardless of whether they’re building col[...]
2013-09-24T09:27:15-07:00[Updated 17-Jul-2013, 12:47 PT: Added a couple of additional links from opensource.com.] It seems to be time to pull together the past year's posts and ideas here. I've not been writing as much on the Network World blog, focusing instead...[Updated 17-Jul-2013, 12:47 PT: Added a couple of additional links from opensource.com.] It seems to be time to pull together the past year's posts and ideas here. I've not been writing as much on the Network World blog, focusing instead on the Outercurve Foundation blog. I've been working to develop a theme on making open source software projects successful. To that end I started around a collection of writing on the basics of understanding the motivations and some of the mechanics: Making Open Source Software starts the theme by looking at the motivations around open source software, whether one is a user, a buyer, or a maker of FOSS, and if you're going to "make", why the economics works and what you need to consider. Making Commercial Open Source Software picks up the theme of the maker but from a commercial perspective. If a company is to contribute or make FOSS, then one needs to have a clear understanding of the return on investment and how to consider certain additional tools at one's disposal for making open source. [This post takes the theme from the idea of developing FOSS as a strategic product/service edge, and doesn't get into the nuts and bolts of customers versus community.] This post appeared in opensource.com as well. Building collaboration communities comes with certain realities. One of the ideas I wanted to develop was the importance of "freeloaders" because if contribution is the lifeblood of a project, one needs a lot of users to find people interested in contributing. I cover these ideas off in "The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success" [opensource.com link] Finally I wanted people to understand the role of software construction practices in scaling FOSS projects beyond a handful of users. If you don't build onramps for potential contributors, you'll never see the contribution potential of your project. These ideas were tackled in "Git[/SVN/Mercurial] and Growing a FOSS Community". [This post also appeared recently on opensource.com.] I also posted this past year from several perspectives on licensing and FOSS. Software is protected by copyright law in the United States and other countries. There has been an enormous rise in the power and popularity of github.com this past few years, but many feel they don't need to worry about licensing their software if they want to share it, living in a "Publication = Sharing" world. Trying to sort out licensing can be daunting at times. Depending upon my frustration levels, I've covered the topic from a number of perspectives this past year: "Open Source, Software Hygiene and STDs" starts the discussion about the problems of not licensing one's software. [Also appearing in opensource.com.] "Which Open Source Software License Should I Use?" tackles the question head on explaining the broad levers available in FOSS licensing. There was a crossover post on Network World discussing licensing versus business models for the commercially minded FOSS advocate. [Also appearing in opensource.com.] Finally I broke down to the very short "Everything You NEED to Know About Software Copyright and Licensing-to-Share in 2 Minutes". [opensource.com link] Lastly, I've written in several places on the "theory of FOSS foundations" that Paula Hunter and I continue to expand on: The most comprehensive discussion is in the International FOSS Law Review in a refereed article Paula and I co-authored "The Rise and Evolution of the Open Source Software Foundation". I tackle the fundamental differences between FOSS Foundations and forges in "Forges and foundation[...]
2013-09-24T09:24:35-07:00I had the pleasure of attending Monki Gras 2012 last week in London, UK. It is a fabulous small conference and that will always be it's challenge. (More on this in a moment.) Monki Gras was probably the best small... I had the pleasure of attending Monki Gras 2012 last week in London, UK. It is a fabulous small conference and that will always be it's challenge. (More on this in a moment.) Monki Gras was probably the best small conference I've ever attended. It was ostensibly a conference about where we're going in software development, tying it back to ideas of craft over industrialization. Following along that theme, we had craft coffee for the breaks, craft beer in the reception and as a tasting at dinner, and enjoyed craft food at the breaks and lunch. The presentation content, however, was incredible. The format was "short" talks lasting 20-30 minutes. It worked well, allowing lots of time to talk amongst the participants. There were ~150 participants and speakers and this was a perfect size. Over the two days, I walked away with something new to think about from almost every single talk. Some highlights for me included (and I'll post slide references as I received them): Excellent observations from Matt Lemay (@mattlemay) from bit.ly on "What we share is different than what we click". Best quote: "We've had social media for long enough to be embarrassed by ourselves." Matt Bidulph (@mattb) talked about new ways to consider social media data analysis and presented ideas for the "Place Graph" alongside the "Social Graph" (see pictures below). In a question: What is the Holborn of Amsterdam? Or the Williamsburg of London? Laura Merling (@magicmerl) walked us through a great introduction to the idea of the "craft telco" building on the history of the telco space, and comparisons to the brewing industry from pure to industrialization to craft. (Think Twilio.) Kohsuke Kawguchi (@kohsukekawa) talked about developing developer communities from his experience in Jenkins and the idea of a developer pipeline (analogous to customer pipelines) and how to get developers qualified through it by making everything relentless easier. Slides here on SlideShare. This talk was a great complement to my blog post on software development discipline and developing communities. I also blogged Kohsuke's talk separately on the Outercurve Foundation blog. Jason Hoffman and Bryan Cantrill gave an enormously entertaining "Doppelbock" talk on the differing roles of CTO and VP, Engineering with some wonderful anti-patterns. Slides here on SlideShare. Best quote from @bcantrill, "Process doesn't write software." Zack Urlocker (@zurlocker) gave a great talk on considerations for distributed product development practices. Mike Milinkovich (@mmilinkov) also gave a great talk on the relevance of foundations in an open source world. (There was a broad debate on the subject back in November 2011.) Those were my highlights from Day One in Conway Hall in Bloomsbury. Okay, I also had the Best Espresso of My Life from the Barista-for-Hire. And the beer tasting at dinner led by Melissa Cole was also awesome. Day Two moved us down to Rich Mix, an equally interesting and completely different venue in Shoreditch. The talks were equally brilliant. My top picks: Gavin Starks gave us great insight into developers and apps driving social change at amee.com. Very cool example of Autodesk integrating with the AMEE environmental data feeds to allow designers to model carbon footprints of designs while still designing, rather than discovering the cost in manufacturing. Paul Downey (@psd) talked about hardware forks and gave us a view of solderpad.com (@solderpad). (Think git for hardware developers only better — very cool.) Donnie Berkholz talked about how much assholes cost projects with examples from the Gentoo world. [...]
2011-11-29T11:53:58-08:00It's been a while since I last blogged here as I continue to post to my Network World blog when I've something to say. Here's a quick summary of what I've been posting over the past year. The Role of...It's been a while since I last blogged here as I continue to post to my Network World blog when I've something to say. Here's a quick summary of what I've been posting over the past year. The Role of FOSS Foundations Clean IP management and neutrality encourage collaborative development. There’s an excellent discussion begun over the past few days on the value of foundations in the free and open source software (FOSS) world. It includes people calling into question the Apache Software Foundation’s role, promoting foundations, and discussing the broader role of FOSS foundations. This was my take. Do Lawyers Ignore Copyright Law? Creating software versus creating contracts and a little irony to start your week. A view on the irony of lawyers ignoring copyright law to make the practice of law easier for them, while making software developers lives more complex. Software Discipline and Open Source Software discipline is critical to successful community development Good software is developed by good software developers. It involves a discipline not found in most programmers. Rigorous version and configuration management, checklists for style and review, “desk” checking reviews before commits, automated (continuous) builds, and fully automated test frameworks are all necessary steps to successfully, reliably delivering executable software that works. I argue that scaling a software project (open or otherwise) is impossible without this discipline. Peace and Harmony between FOSS contributors and lawyers Version 1.0 of the The Harmony Documents Launch Harmony is an effort that was begun and shepherded by Amanda Brock, the general counsel at Canonical, makers of Ubuntu Linux. The intent was to create a small collection of consistently-worded contribution agreements (both licenses and assignments) for free and open source projects to use to reduce the friction such agreements can cause when they’re encountered for the first time by corporate counsel unfamiliar with FOSS licensing. The first version of the work was published in July, 2011 and this was my take on it. Re-inventing SuSE and Three Futures for Mono Imagining the potential for Mono going forward In June 2011 we saw the rolling announcements out of Attachmate as SuSE gets spun into a separate organization with a return to Germany and Mono employees (along with many other Novell employees) finding themselves on the outside looking in. Here were three ideas for the future of SUSE and Mono. The End of the Symbian Foundation The end of the Symbian Foundation was in sight before it ever began. My analysis of how the Symbian Foundation failed before it ever got going properly. Red Hat Obfuscation is a Tempest in a Teapot Voting with one’s pocketbook and one’s feet is exactly what software freedom is about. I encounter another reference in the mainstream analysis about Red Hat “obfuscating” their work on Red Hat Enterprise Linux. This really is a tempest in a teapot, and I outline why I think that's so. Solving the Apple App Store Incompatibility with the GPL What’s needed is a little legal linguistic grease to enable the two orgs and their differing goals to slide by one another. Here was an idea for all open source legal experts to gnaw on and solve for the community. I saw that Apple pulled down the VLC media player because of the conflict between the GPL and the Apple App Store terms of service. I think there are easy ways around the GPL software on Apple Appstore debate. I will keep posting collections here from time to time t[...]
2010-11-29T03:42:25-08:00I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the... I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the discussion around open source community, business, and IP management Of Coffee Houses and Code Communities We can learn a lot about successful community building from Starbucks Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident and it differentiates between the co-creation of the asset and the co-production of the community. Makers, Users and Buyers of Open Source Software Understanding your relationship to a project lets you ask the right questions. More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance. I try to frame a participants relationship to a project so they can best understand what they do (and don't) need to care about. How to Talk to Your Lawyer about Open Source Software Lawyers know surprisingly more than they think about open source software. If you’re a developer that wants to use free and open source software then sooner or later you’re going to need to talk to a lawyer. Many developers have a working understanding of software intellectual property, but unfortunately software copyright is a space fraught with exceptions and edges and ambiguities. Karen Copenhaver came up with a great way to explain open source to a lawyer, and I managed to find the recording of it again. It’s Not That Complicated Too much is being made of FOSS licensing complexity. We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. I'm tired of it. It's just not that complicated to maintain a clean IP environment in software development. Please Don’t Confuse Standards with Open Source Software While standards and FOSS may overlap, they can’t be merged into one mega concept Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community. Open Source: No one is working for free To understand the economics of open source, look to the R&D of collaboration. People continue to wonder how to make money in the free and open source software world. It’s dressed up in discussions of how one makes money when you give away the software for free, or why developers are working for free. It can likewise lead to a management backlash of not contributing to FOSS projects because some think their developers are working on FOSS instead of their own work. I take another run at explaining why the economics is in a business's best interests. A FOSS project isn’t necessarily a software product For FOSS the question isn’t just build vs. buy but also borrow versus share. Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? [...]
2010-11-29T03:14:24-08:00So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far: The Patent Purchase Agreement provides that, upon the terms and subject... So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far: The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”). N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below. Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find: Patents with Novell as Assignee Name or Novell as Inventor Name: 467 Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290 So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them. So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago. [...]
2010-09-28T07:13:01-07:00The CodePlex Foundation has re-branded itself to the OuterCurve Foundation. There continued to be confusion between the Foundation originally sponsored by Microsoft and the Microsoft forge site (codeplex.com). In June the Board decided it was time to rebrand the organization... The CodePlex Foundation has re-branded itself to the OuterCurve Foundation. There continued to be confusion between the Foundation originally sponsored by Microsoft and the Microsoft forge site (codeplex.com). In June the Board decided it was time to rebrand the organization to clear up the confusion. [Most recently we were given credit for some excellent sponsor work the forge did in the open source community, so we knew the rebranding work was still necessary.] We worked with a professional agency (Protobrand) and investigated a number of names that conveyed attributes we wanted to have associated with the Foundation. We wanted the name to support our efforts to build credibility for the Foundation within the open source community, and make the Foundation an attractive investment for additional sponsors. And of course we also had to find a name where we could own the urls. In the end we chose the OuterCurve Foundation. We hope it conveys our goal of helping the expanding universe of companies using open source to contribute to the communities they care about and to create their own. A number of press articles have positioned us as "putting some distance between Microsoft and the Foundation" as the rationale for the rebrand, and I want to emphasize that the distance we're hoping to create is between the forge and the Foundation. We have an excellent working relationship with Microsoft as our founding sponsor. The Codeplex name was originally chosen as there was thought to be more affinity between the forge and the Foundation but it proved not to be so. Not every plan is flawless in its entirety. The rebranding also coincides with our anniversary. The Foundation is now a year old. In that year, the interim Board put an initial governance structure in place, hired core staff (Paula and I) and we have accepted the creation of two galleries and a half dozen projects. More are on their way. The mission hasn't changed. The Outercurve Foundation exists to provide a software IP management process and project development governance to enable organizations to develop software collaboratively and encourage the growth of the open source software as a development methodology. It's an exciting time. Some of the coverage: Dana Blankenhorn: CodePlex Foundation becomes OuterCurve Joab Jackson (NYTimes): CodePlex Foundation Called OuterCurve The Register: MS-backed CodePlex Foundation morphs into Outercurve [And no, Paula doesn't gush about things.] DJ and H-Online: CodePlex Foundation becomes Outercurve Foundation [...]
2010-08-10T18:03:50-07:00Companies have been concerned about software license compliance with respect to free and open source software for some time. Part of this is due to simple competitive FUD designed to frighten people away from using FOSS or to sell services...
Companies have been concerned about software license compliance with respect to free and open source software for some time. Part of this is due to simple competitive FUD designed to frighten people away from using FOSS or to sell services and tools around it, and part of this was due to genuine concern with license compliance when lawsuits appear because of violations. The Linux Foundation announced the Open Compliance Program at LinuxCon in Boston today to help companies understand and manage such compliance needs. I describe and comment on the program on my CodePlex Foundation blog.
2010-07-13T22:07:06-07:00The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable...
The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).
I add my take on the debate on the CodePlex Foundation blog.