Posted on

Open Hardware: Good for Your Brand, Good for Your Bottom Line

Article originally published in the June 2018 issue of Linux Journal

I don’t know how to put this, but Hardware is kind of a Big Deal, and thanks to the Internet of Things (aka IoT), it’s getting bigger every year. The analyst firm IDC expects spending on IoT to reach nearly $800 billion USD by the end of 2018. A study by Intel shows that by 2025 the global worth of IoT technology might be as high as over $6 trillion USD, whereas Forbes reports that the global market could be nearly $9 trillion USD in 2020.

These statistics are based on the traditional model of closed design and development of the chips, boards, and objects that will make these devices a reality. However, what if hardware developers were to learn from and leverage the popularity of free and open source software (aka FOSS)? What if the future of IoT were Open? It’s my belief that the device developers who apply the lessons of FOSS to hardware development will be those best positioned to become the powerhouses of that $9 trillion market. Similarly to software, open hardware will be seen first as a differentiator (rather than an eccentricity) and later, as the industry matures, as the default operating mode for hardware development.

Open hardware will require a lot of evolution before it becomes the default development paradigm for IoT. The current state of open hardware closely resembles that of free software thirty years ago: it exists, but in a nebulous form. While organisations such as the Open Source Hardware Association and the Open Hardware Repository are working to change this, the fact remains that there currently are few clear legal, social, or procedural norms around open hardware development. There is no hardware equivalent of the Open Source Initiative‘s list of approved licenses, or agreement on whether a license is even needed at all. The diversity of tools required for hardware design makes collaboration and interoperability more difficult. These legal and procedural questions contribute to a very high barrier to entry for releasing designs as open hardware. That barrier isn’t insurmountable, however. Already advancements in 3D printing as well as emulation and virtualisation through digital twins are enabling types of collaboration that were impossible just a few short years ago. As these methods continue to adapt, the resulting emergent and open processes and norms will drive further and faster innovations.

The openness of hardware will also be hampered for a while by the limitations imposed by chip makers. For instance, the n Mark I voice assistant speaker is certified as open hardware, but includes components built upon proprietary chipsets and boards. Joshua Montgomery, CEO of Mycroft, sees this as a valuable stepping stone toward an entirely open hardware platform. “For now, a lot of open hardware is like LEGO™: while the bricks themselves aren’t open, the designs built with them can be.” This stepping stone has enabled Mycroft to iterate on the Mark I, which incorporates off-the-shelf hardware like Raspberry Pi and Arduino, to create the Mark II, which features a board custom- and openly-designed for security, privacy, and flexibility.

Chip makers are starting to catch on to the advantages of open, however. SiFive has released an entirely open RISC-V development board. Its campaign on the Crowd Supply crowd funding website very quickly raised over $140000 USD. The board itself is hailed as a game-changer in the world of hardware. Developments like these will ensure that it won’t be long before the hardware equivalent of those LEGO™ bricks will soon be as open as the designs built using them.

In the March 2018 issue of Linux Journal I encouraged companies to wait until they’re secure and established in their market before releasing mission-critical software as open source. The reason here is, of course, that it’s quite simple for someone else to take that software, spin up a new cloud instance, and create a company that competes in your market. There are very good business reasons for a company retaining its software intellectual property until the company has locked in its market.

However, that’s not currently the case for hardware. The complexities involved with manufacturing are far more daunting than those around launching a new software firm. The knowledge, regulations, testing, and tooling involved with bringing new hardware to market create a massive—and massively protective—barrier that’s compounded by those undefined legal, social, and procedural norms I mentioned earlier. This provides open hardware startups the freedom to share their designs after (or even before) product launch while still retaining prime mover advantage, simply because no other company would be able to spin up the tooling required quickly enough to impact the sales and market of that prime mover. Once a piece of open hardware is released to customers, the company creating it is already so far ahead of any others that would use its designs that there is little danger of market loss or competition. According to Josh Lifton, CEO of Crowd Supply, even after helping hundreds of creators launch their open hardware products on the platform, “…we have never gotten any report of an idea from a Crowd Supply project getting stolen.”

While open hardware does not share free and open source software’s business risks for releasing of intellectual property, it does share its difficulties in attracting contributors and building a community. While both open endeavours represent the field of dreams for creators, it remains true that if you build it, they will not necessarily come. This is especially true for open hardware where people are not only less used to the idea of contributing, they’re also often less prepared to do so. Aside from the specialised tooling required to read, manipulate, and understand hardware design files, there’s the additional problem of a knowledge gap. Relatively speaking, far more people are equipped with the knowledge and resources necessary to contribute to FOSS projects. When source files are distributed for a free and open source software project, many people already know what to do with them. When source files are distributed for an open hardware project, comparatively few people will have the electrical engineering, industrial design, stress analysis, or other related experience (let alone the very expensive tools required) to contribute effectively. While this naturally leads to considerably fewer contributions to and collaborators on an open hardware project, it also means that those collaborators are more likely to be qualified and their contributions of a higher quality.

Hope of contributions should not be the primary reason for releasing hardware designs under an open license. As Kaia Dekker, CEO of Keyboardio points out, building a business while relying on volunteers for contributions “really isn’t something that necessarily works out.” This is a consideration that’s overlooked by a lot of the new breed of “open first” software businesses springing up these days, but that the sparse contributions make impossible to ignore for open hardware.

Despite this, open hardware still allows companies to reduce the time and expense required for research and development. For instance, Dekker says, developing the Keyboardio Model 01 would not have been practical without the open platform of Arduino or the vibrant community around it. Open hardware components are similar to libraries or modules for software: they allow an organisation to add functionality without having to develop it themselves. Entirely new products, such as the Keyboardio Model 01 or the Mycroft Mark I can come to market thanks to what are essentially off-the-shelf open hardware components.

Joshua Montgomery of Mycroft AI points out that as important as the R&D benefits were to their company when they were getting started, they’re finding that opening the new design of the Mark II is also opening possibilities that they’d not have seen had they kept their hardware proprietary. Through careful design of the Mark II board, Mycroft has created a new off-the-shelf component that partners and other businesses can use, in combination with the open source Mycroft Artificial Intelligence platform, to add a voice assistant feature to their own devices. This increases adoption of the AI platform software along with the contributions and collaborators on it.

By designing their hardware to work in many different contexts then releasing it as an open solution, Mycroft also has gained the benefit of economy of scale for themselves as well as for all companies using the open component. When all companies order the component from the same manufacturer, the subsequent “run” of the part becomes cheaper for every company that uses it. This open supply chain also reduces risk for all participants. Should a supplier fail or withdraw from manufacturing a component, with open hardware it’s possible to spin up tooling in another location. With proprietary hardware, it’s possible if not likely that companies reliant upon that component will need to redesign their products when a component is no longer available. Naturally this type of economy of scale will depend a lot upon the market and company strategy, but the Mycroft example, even in these early days of open hardware, proves that the open approach can provide innovation opportunities and benefits to innumerable companies and entrepreneurs.

According to Kaia Dekker, none of these benefits would be possible without the communities that form around open hardware projects. “It opens doors to us that would be closed otherwise.” Keyboardio has found unexpected success in recruiting firmware development and other talent from their community. That same community can develop after-market accessories for the Model 01, adding, if they wish, features such as wireless capability thanks to the open hardware at the core of the device. This ecosystem of accessories as well as the supportive community has strengthened the Keyboardio brand as their community members have become their most passionate and outspoken advocates. Keyboardio has found that the transparency has increased their perceived reliability in the eyes of their target market, which itself increases the market’s trust in them. Josh Lifton agrees and says that many Crowd Supply creators have seen similar results. “A lot of these people are early adopters and innovators. This type of person usually has a strong community-minded ideology.”

The transparency of open hardware does more than build trust in its communities. It also builds trust in the entire customer base. According to Joshua Montgomery of Mycroft, the “radical transparency” of the Mark I and Mark II devices help to support their reputation for privacy and security. Increasingly, this sort of reputation can have a huge impact on companies looking to enter certain markets. Open hardware ensures that there is never a black box. Consumers, regulators, and security auditors all have equal access to the designs of the devices. In an environment where customers are more privacy aware than ever, this type of transparency can be a powerful differentiator for products.

In 1997 Clayton Christensen detailed the dangers of ignoring the new paradigms in business in The Innovator’s Dilemma. Hardware and IoT creators today are at risk of stumbling straight into that dilemma if they don’t embrace the type of innovation and collaboration that free and open source software has proved is possible. While the ecosystem and contribution norms are still taking shape around open hardware, it’s clear from the benefits listed above that the current environment provides enormous opportunities for companies willing and able to work with and mold that ecosystem. The companies that recognise this now are those that will lead the way for several decades to come.

Posted on

The Past, Present, and Future of Open Source

Last week Christina Cardoza of SD Times published an excellent article about the first 20 years of open source. I was interviewed for the article, but naturally only part of the interview was used (there were other excellent folks to speak with as well).

Here’s the complete text of that interview.

What really marked the start of open source software in your opinion?

What really marked the start of open source software was the start of Free Software. Without the genius insight of Richard Stallman (aka RMS) that existing copyright and licensing mechanisms could be leveraged to enable the distribution and sharing of software—freely and openly—none of us would be here talking about this today. There would have been no open source software history without the work of GNU, FSF, GNOME, and others. All of software development owes them a huge debt.

Any “start” demarcation beyond that assumes that open source software is an entirely different thing from free software, and that’s just not true. While there may be exceptions, generally speaking all free software is also open source, according to the open source definition. Beyond that there’s a spectrum starting at the stalwart reciprocity of the GPL and the Four Freedoms and running through to the neutral permissiveness of MIT licensed software.

Each end of this spectrum—and every point on it—is a philosophy, and each has existed since people started thinking about the nature of software. Therefore I don’t think there’s any way you can point at a single moment in the history of software and say, “There. That spark right there. That’s open source being born.” It’s not really possible. The release of Netscape or of Java may have captured mindshare and imaginations, but they’re lagging indicators of the birth of open source, not leading ones.

What did the open source landscape look like 20 years ago, and how have you seen it evolve?

Twenty years ago is right around when I was starting my tech career, so while I was aware of, used, and advocated for free and open source software I was more focused on finding my place in tech and paying off student loans than on contributing and becoming a part of the community. I didn’t become really dialed into the FOSS landscape for another three or four years, and wasn’t able to travel and explore that landscape widely for several years after that.So with that in mind…

I like to think of free and open source software as evolving through epochs or versions, much like any software would. FOSS v1.0 was the the dawn of Free Software thanks to RMS and the thousands of others who helped to bring Free Software into the world. This version is usually considered more “wild west” and programmer-driven. Programmers building tools for programmers, driven by a philosophical belief that Sharing Is Good And Right.

The launching of the Open Source Definition and the creation of the Open Source Initiative also brought with them the beginning of FOSS v2.0. In this version FOSS gained mindshare and acceptance, becoming normalised.

What we’re witnessing now is the beginning of FOSS v3.0. Free and open source have evolved from niche and mission-driven movements into Business As Usual. Version 3.0 is rocketing in—propelled by an explosion of corporate involvement, contribution, and sponsorship—but at this speed there’s a very real risk of losing sight of the mission and the bigger picture of FOSS. How are we in the free and open source software communities going to work with the corporations to teach them the human and business benefits of that bigger picture, and how are we going to help them continue to be involved, to contribute, and to sponsor FOSS, but also and importantly to understand and respect that mission? It’s a critical question and one not enough people are discussing.

What do you think was the tipping point for enterprises to realize the importance of open source software?

To be honest, most of them still haven’t realised the importance of free and open source software. I’ve seen companies shut down their open source programs. I’ve seen companies swear they don’t use any open source software and then seen the stunned looks on their faces when they’re shown how much of their stack is free and open source software. I’ve seen companies release fauxpen source, either by throwing unlicensed and unsupported projects over the wall and calling them “open source” or by releasing them under proprietary licenses and claiming they’re “open source” when at best they may be “source available.”

While, yes, there is that explosion of corporate involvement, contribution, and sponsorship, it’s fueled by a tiny fraction of companies. We’ve come a long way, and it’s been wonderful to be along for the ride, but it’s unfair to say that we’ve already crossed the tipping point as there’s still so much work yet to do. That’s our task as we develop and evolve FOSS v3.0.

What is the state of open source software today, and what areas still need to be improved?

For all the decades of their existence, the predominant development approach of most of free and open source software has been “by programmers for programmers.” That’s gotten us this far, and that’s great. However, we’re not going to move FOSS much further if we don’t shift from that approach to one of “by programmers for others.” The usability, accessibility, and documentation of most FOSS projects are in such a state as to be entirely out of reach of people who don’t spend their lives steeped in technology and software development. We’re not going to further the missions of free and open source software if we can’t start developing software that reaches out to a new market of users and, most importantly, meets them where they are rather than expecting them to read code, edit config files, or open up a terminal just to perform basic tasks. If FOSS can’t expand beyond the server and the enterprise then it will never realise the dreams that brought it to life in the first place.

Answers (c) VM Brasseur; Licensed CC BY-SA

Questions (c) Christina Cardoza

Posted on

FOSS as a Part of a Corporate Sustainability Plan

Article originally published in the May 2018 issue of Linux Journal

Free and open source software is a critical part of your company’s supply chain. Here’s why and how you can include it in your corporate sustainability plan.

In 1983 the United Nations convened a commission of 22 people to investigate the question of the worldwide environmental and social impact of human development. Four years later, in 1987, the commission released Our Common Future, more commonly known as the Brundtland Report in honour of Gro Harlem Brundtland, chairperson of the commission. This report detailed the very real socio-environmental issues facing humanity. One of its recommendations was for governments, organisations, and companies to start engaging in what it called sustainable development. That is, “…development that meets the needs of the present without compromising the ability of future generations to meet their own needs.”

Since then there’s been steep growth in the number of corporations that maintain and operate according to a corporate sustainability plan. These plans encompass environmental as well as social aspects of doing business. They encompass actions within an organisation—such as natural resource usage, diversity and inclusion, and fair treatment of employees—as well as those external to the organisation—such as the sustainability operations of their entire supply chain as well as the overall impact the corporation has on the Earth and its inhabitants.

The benefits of sustainability

A sustainability plan impacts every facet of an organisation’s operations and can take a fair bit of effort to implement and maintain. If that’s the case, then why are more corporations putting these plans into action every year? While it would be nice to think that this occurs for entirely altruistic reasons—taking care of the Earth and its inhabitants is simply the right thing to do, after all—the fact of the matter is that studies repeatedly show that properly implemented corporate sustainability plans are very good for the bottom line.

Innovations and profitability

Sustainability requires partnering and collaborating not only across groups within the organisation, but also with many external to it. These collaborations expose a corporation to new ideas and innovations in market, process, policy, and product, all of which can lead to improved profitability while moving the company toward its sustainabiity goals. Without the support and engagement of all employees, a sustainability plan will fail. Therefore the execution of a sustainability strategy requires a shift in management from the old style of command and control toward a modern style of trust, communication, and employee development. By empowering and training employees, a sustainable corporation improves its ability to execute plans while also increasing employee satisfaction and retention. Beyond just innovations, profitability is increased through reduced expenditures, entry into new markets, and a lower cost of capital.

Investments

Investments are also impacted, as more investors are now looking at a corporation’s sustainability plan as a deciding factor on where to place their money. When you think about it, it’s surprising that sustainability hasn’t been a primary investor consideration before now. The strategies that support a successful corporate sustainability plan, focusing on what’s good for society and the environment, are also those that do good for the company. Protecting the organisation’s value and supply chains enables it to ensure it will be around for a good, long while. That longevity—and plan to maintain it—is very appealing to investors in search of both stability and a positive return on their investments. Despite this, studies show that most high level corporate managers still don’t recognise the importance sustainability holds for investors. This provides a great opportunity for those managers who can launch and make a corporate sustainability plan successful before their competitors.

So, yes, corporate sustainability planning (when done properly) is that proverbial rising tide that floats all boats. However, for companies that rely upon technology to keep their business operating (read: all of them), there’s a major component that’s usually left out of their sustainability plan: the software.

Open source software is a part of your supply chain

Operating systems, databases, libraries, infrastructure management and orchestration… No matter what component, all software is a part of your company’s supply chain. How much do you know about it? Do you know what your company’s software supply chain looks like? How much of that chain is or depends upon free and open source software? If you haven’t investigated this before, you’ll likely be surprised by the answer. If you look at little deeper, you’ll be even more surprised to discover just how few people maintain and support the software on which your company relies to operate and do business.

However you look at it, this arrangement is fraught with sustainability concerns. Socially, allowing so few people to perform so much work for so little compensation is inappropriate and does not scale. From a business perspective, it’s very poor practice to rely upon suppliers who may burn out and disappear at any moment. This does nothing good for the longevity prospects for your organisation and dramatically inceases its risk profile.

Open source software is good for sustainability

Don’t get the wrong idea: I’m not here to spread Fear, Uncertainty, and Doubt (aka FUD) about having free and open source software projects as a part of your supply chain. Even a quick glance will show that you’re unlikely to receive as much value and flexibility from proprietary solutions (if they even exist). Proprietary software is incredibly expensive, less flexible, leads to vendor lock-in, and is at least as likely to disappear without notice. 90% of software startups fail, taking their products and their code with them. The high cost, low innovation, and equal risk of mortality for proprietary software makes it a less appealing solution when considering the longevity and sustainability of your own company. Free and open source solutions are simply the better option.

What is YOUR software supply chain?

The answer, then, is not to cut out the free and open source links in your supply chain. No, the actual answer is to include free and open source software in your corporate sustainability plan. Unlike proprietary software, free and open source (FOSS) solutions enable your company to take action to ensure that the FOSS projects themselves are sustainable. So, how can your company do that?

For starters, if you haven’t done so yet, take this opportunity to become very familiar with your company’s software supply chain. Certain links in that chain will be more important and more strategic than others. While your software sustainability efforts should include all of the links in the chain—FOSS or proprietary—you may find that it makes sense to focus more of your investment in these strategic links.

Build a culture of contribution

As you’re evaluating and integrating your software supply chain into your corporate sustainabilty plan, start communicating internally about the importance of this supply chain. This communication should be across the entire organisation, not simply constrained to the technical departments. By communicating and including the entire company, you open up more avenues for ideas and innovations in sustainability as well as start to build a culture of sharing and contribution that will aid in all your sustainability efforts, FOSS or otherwise.

That culture of contribution will be critical for the next step: empowering staff members to contribute back to the FOSS projects on which your company relies. Reporting bugs and requesting features is one way to contribute, but fixing bugs, adding features, and contributing those changes upstream to the main project is what will lead to improved project longevity. It often can make sense for a company to pay team members to work full time maintaining and enhancing strategic free and open source software projects, but even small contributions submitted by individuals scattered across the organisation can aggregate into a large amount of work toward sustaining projects on which your company relies. Making it easy for team members to contribute will make it much more likely that they will support the projects through their contributions. Remember, too, that FOSS projects need more than just programmers in order to thrive. Enabling contributions from your QA, design, marketing, and other departments will enhance the entire ecosystem of the free and open source software that enables your company to operate, adding to its longevity and reducing risk both for it and for your own company.

Share the load

As you review your software supply chain, consider the problem that each one of those links in the chain is there to solve. Your company is not the only one to have those problems. These are issues faced by many organisations, and no one company will be able to solve these shared problems.

Therefore the next step in integrating free and open source software into your corporate sustainability planning is to release the software your company has developed to solve problems shared by others. Of course this doesn’t mean you should necessarily release the software that provides legitimate market differentiation and value for your company, but there are undoubtedly several tools developed internally that are not of strategic market value but that solve specific problems. By releasing these tools, you enable collaboration with organisations that share similar problems.

By working together to solve these problems through free and open source software, all collaborators share the load of development. This allows them to benefit from the tool while also freeing up internal resources to focus on strategic value creation for their markets. In a case study created by Open Tech Strategies and released by the World Bank, collaboration on free and open source software tools led to a 200% return on investment for the collaborators. Sharing the burden of maintaining these tools ensures their longevity and stability while reducing institutional risk. The end result is a more sustainable business and a healtier free and open source software ecosystem.

Join a Foundation

Depending upon the free and open source software in your supply chain, one approach toward sustainability may be participating in the organisations and foundations formed to support projects that are strategic to your company. By joining organisations like Open Source Initiative, Eclipse Foundation, Apache Software Foundation, and the Linux Foundation, your organisation not only has a seat at the table when discussing the future of strategic FOSS projects, it also gets the opportunity to meet, discuss, and collaborate with companies it may not have had occasion to interact with otherwise. By bringing together disparate organisations and providing not only a shared purpose but also a safe environment for collaboration, these foundations enable member companies to learn from each other and to open the doors for new partnerships and innovations.

Think strategically

I’ve said it already in this article but it’s worth repeating that, just as with the rest of your corporate sustainability plan, it’s crucial that your company’s approach to supporting free and open source software projects be strategic. While it’s tempting to contribute to all FOSS projects equally—and certainly the projects themselves would not complain—from a sustainability point of view your organisation should try to focus its resources on those projects that make a material difference to your company. Material difference means that a project, were it to stop being developed or maintained, would severely impact the operations of your company. These are the FOSS projects most directly linked to your organisation’s longevity, and also makes them risk factors for your corporate sustainability plan.

In order to determine which projects are material to your corporation, you must be fully aware of your software supply chain. This involves not only looking at the free and open source software that allows your company to operate, but also digging deeper to learn on what projects those projects rely. It’s all well and good to acknowledge that the authentication library used for your product is material to company longevity, but if that library itself relies upon cryptographic functionality in another—woefully under-funded—project, your company may be exposed to unforeseen but preventable risks. Ignorance of your software supply chain is no defense against vulnerabilities. Cultivating an awareness of the entire ecosystem within which strategic and material FOSS projects operate will help secure corporate longevity and sustainability.

Make a business case

Focusing software sustainability efforts on material and strategic concerns makes it considerably easier to incorporate free and open source software into the business case for your company’s corporate sustainability plan. It may be tempting to skip this step, but if you do so studies show that it’s likely your sustainability plan will fail. When you pause to consider this, it makes perfect sense. Why should a corporation invest so many resources in shifting the way it does business, up to and including its very business model, if there is nothing in it for them? Again, setting aside altruistic appeals and the fact that taking care of the Earth and its inhabitants is just the right thing to do, being able to make a well-researched and detailed case that doing so is good for the bottom line makes it more likely that even the less environmentally- and socially-minded leaders in your company will get on board with the plan. Don’t simply list what changes will be necessary to enact a corporate sustainability plan, but also reveal exactly what is in it for the company for making this effort.

You’re all in this together

As mentioned earlier, it’s important for any corporate sustainability plan to create a culture of contribution across the entire organisation. If upper management does not communicate what the plan is meant to accomplish and why, it will fail to get the support of the employees who actually have to do the heavy lifting of implementing that plan. Without the support of the entire organisation, your corporate sustainability plan will fail. Sustainability must be a 360 degree effort, not simply something dictated from on high. All members and stakeholders of the company must understand what the sustainability plan is, what impact it will have, what part they specifically will play, and how they will make a difference to the overall outcome.

This communication is hard enough when the plan is simply about environmental and social concerns, issues with which most people are familiar, but it becomes much more difficult when unfamiliar concepts like “free software” and “open source” enter the mix. This is why it’s so important to begin the discussion as early as possible. It can take some time for people to understand that “contribute back to free and open source software projects” can be as meaningful and impactful to the corporate sustainability plan as “reduce water usage,” “use energy from renewable sources,” or “eliminate the gender/race pay gap.”

To help with this communication, rather than dictating implementation details to middle management, company leaders should instead set software sustainability goals for each team or department and then allow each group to define how it can best contribute toward those goals. For technical departments their contributions may be as straightforward as providing patches or releasing internal tools, while less technical departments may come up with less obvious approaches to helping the effort. By empowering each team to approach the problem in its own way, the company is not only encouraging innovation but it’s also building trust within its ranks. This trust, as mentioned before, increases the effectiveness not only of the sustainability plan but also of other operations undertaken by these teams. This trust also leads to higher employee satisfaction and retention. The overall culture of the company evolves into one that is more collaborative, innovative, and therefore sustainable.

Keep yourself accountable

A vital part of any corporate sustainability plan is the company holding itself accountable for delivering on its promises to itself, to its stakeholders, and to the communities on which it relies. Fostering a culture of collaboration includes supporting open communication. That openness must permeate all levels of the company. Embracing and supporting free and open source software and their underlying values can help to cultivate the communication required for accountability. Instituting inner sourcing is a good way to encourage collaboration, communication, and cross-functional accountability on your corporate sustainability plan.

Accountability can also be included at an organisational level by way of performance reviews. For this to work, each employee must understand how they contribute to the overall corporate sustainability plan so that they can work toward meeting their particular goals. This is especially important at the executive level. When leaders are held accountable for their sustainability strategies and plans, it reinforces the importance of the effort to the organisation and encourages participation by all members. Reporting on the company’s progress on its sustainability plan also provides accountability to external stakeholders like investors, partners, and customers. For many companies, it can be uncomfortable at first to embrace this form of open communication both internally and externally, but if they are able to make this shift they’ll reap the benefits of sustainability. It can be a difficult journey, but it’s one entirely worth taking.

Posted on

Do I have to use a free/open source license?

Article originally published in the March 2018 issue of Linux Journal

Man thinking at a deskA few weeks ago I ran into a neighbor, whom I’ll call Leo, while he was out taking his dogs to the park. Leo stopped me to ask about some software he’s developing.

“Hey, you do open source stuff for companies, right?” Leo asked.

“Yeah, that’s my freelance business. Do you need some help with something?”

“Well,” he said, “I’m getting ready to release my software and it’s time to start thinking about a license. Which open source license should I use if I want people to know it’s OK to use my software but if they make money from it they have to pay me?”

I blinked, stared at Leo for a moment, then answered, “None of them. No open source licenses allow for that.”

“No, you see,” he continued, “this guy told me that there must be plenty of licenses that will let me do this with my software.”

“Plenty of proprietary licenses, maybe,” I explained, “but no open source ones. According to Item 6 in the Open Source Definition, no open source license may prevent someone from making money from software released under it. That’s what you’re suggesting, and it’s not possible to do with an open source license.”

Leo did not seem pleased with this answer. “So what you’re saying,” he fretted, “is that I can’t release my software at all!”

“No, no!” I assured him, “You definitely can release and distribute your software. You’ll just have to get an intellectual property lawyer to help you write the proprietary license you want, and maybe to help you release it under a dual license (one open source and one proprietary).”

He nodded (not altogether happily), and headed off to the park with his now very impatient dogs. I continued my walk, pondering what I’d just experienced.

The thing is, Leo was not the first person I’ve spoken to who assumed that software had to be released under an open source license. I’ve had multiple conversations with different people, all of whom had mentally equated “software license” with “open source license.”

It’s easy to understand why. Of all software pursuits, only free and open source software is defined purely in terms of its licenses. Without that license, a piece of software cannot be either free or open. This leads to a greater focus on licensing than for other types of software, which then itself gains a lot of mindshare. The larger intellectual property concept of “licensing” becomes so closely associated with “open source,” and is often the only context in which someone hears of licensing, that people understandably start to assume that all licenses must therefore be open source.

That, as we all probably already know, is not the case. The only licenses that can be called “open source” are those that are reviewed and approved as such by the Open Source Initiative (aka OSI). Its list of OSI-Approved licenses allows developers to choose and apply a license without having to hire a lawyer. It also means that companies no longer need to have their own lawyers review every single license in every piece of software they use. Can you imagine how expensive it would be if every company needed to do this? Aside from the legal costs, the duplication of effort alone would lead to millions of dollars in lost productivity. While the OSI’s other outreach and advocacy efforts are important, there’s no doubt that their license approval process is a service that provides an outsized amount of value for developers and companies alike.

OSI approves or rejects licenses as qualifying as “open source” by comparing them to the Open Source Definition. A license must not violate any of the sections of the definition in order to be added to the list of approved (and therefore open source) licenses. Aside from the, “you can’t prevent people from making money from it” precept mentioned above, other requirements contained in the Open Source Definition include non-descrimination (you may not prevent certain people or groups from using your software), that the license be technology neutral, and of course the requirements of the Four Freedoms as originally defined by the Free Software Foundation. If you haven’t read the Open Source Definition before (or not for many years), I encourage you to do it again now. It’s an important and powerful work that is the foundation for much of how many of us spend our days.

It’s worth stressing again that no license can be called an “open source” license if it does not adhere to the Open Source Definition. Full stop. No exceptions. It’s illogical to think that something that doesn’t meet the official definition of open source could ever legitimately be called open source. Yet people try it every day mostly because they, like Leo, don’t know any better. Thankfully, there’s an easy way to fix this. It’s called Education.

Basically, you only have to choose from two different types of licenses:

  1. Free and open source: If you agree that the software you want to release should obey the Open Source Definition, then you should select one of the OSI-approved open source licenses from the list they provide. You may still need an IP lawyer to help you make the correct license selection, but you’ll need considerably less of their time than if you weren’t to use one of those licenses.
  2. Proprietary (and likely custom): If there are any parts of the Open Source Definition that you don’t want to apply to the software you want to release, then you’ll still need a license but it will have to be a proprietary one likely custom-written for your purposes. This absolutely requires an IP lawyer. Where licenses are concerned, you should never roll your own. Copyright and licensing are very complex legal issues that you should in no way undertake on your own without professional assistance. Doing so puts yourself, your software, and your organisation at risk of large legal problems.

To be clear here: There is nothing wrong with using a proprietary license for the software that keeps the lights on at your company (figuratively speaking). While I, personally, would prefer everything be free and open, I also prefer that companies remain solvent. To do that, it’s usually necessary for some software to remain proprietary, if only for a while. It’s bordering on business malpractice to release the “secret sauce” of your company’s product offering without a business model that will allow the company to remain or become profitable. Once your company has established itself and is secure in its market, only then should it consider releasing its mission-critical software under an open source license (and I do hope it does do so).

Companies like Amazon and Google can release critical infrastructure as open source because they no longer really compete on product, they compete by having scaled to a point that no newcomer to their product spaces could possibly replicate. If tomorrow Amazon were to release the software for S3 under the GPLv3, it’s unlikely it would at all impact their profitability. The number of companies that could take this code and spin up and scale their own product offering with it and do so in a way that could compete with Amazon’s existing dominance and scale? Vanishingly small, and those that could do it are unlikely to be interested in doing such a thing anyway (or already have their own solutions).

With open source as with all technical and business decisions: Do not do something simply because the big players do it. Unless your company has the advantages of scale of an Amazon or a Google, please be very careful about open sourcing the technology that pays the bills. Instead, hire a good intellectual property lawyer and have them write you a proprietary license for the critical software that you distribute.

Posted on

Using Slack with IRCCloud

A while back I wrote a guide on how to add a Slack team to your ZNC IRC bouncer. Soon afterward, I switched from using ZNC to IRCCloud. I’m consistently impressed by the service and stability of IRCCloud, and the handoff between desktop and mobile clients is seamless. I love it.

The one thing I haven’t bothered to do since switching to IRCCloud is figure out how to add a Slack team to IRCCloud as a network. To be honest, it’s more that I haven’t needed to than I haven’t bothered to. I’m sick to death of the constant barrage of Slacks I’m asked to join, so I’ve stopped using them altogether. I just don’t have that much time in my day. However, if I do have to do the Slack thing then I’d rather it were in my IRCCloud client so at least I don’t end up with Yet Another Damn Chat Client open on my devices.

So here are the steps for adding a Slack team as a network on IRCCloud. It’s not complicated, but it’s worth documenting in the hopes of making someone’s life just a little easier as they try to manage joining their 25th Slack team.

  1. Have the Slack team administrator enable the IRC gateway
  2. Visit the Gateways settings on your account on that Slack team. The Gateways URL is https://$SLACKTEAMNAME.slack.com/account/gateways. Leave this tab open, as you’ll need the information from it.
  3. Log into your IRCCloud account.
  4. On IRCCloud, click Add a new network in the Account settings and info menu.
  5. Copy the Server value from your Slack team Gateways page and enter it into the Server field on the IRCCloud form.
  6. Verify that the Server port is set to 6667 and check the secure port box. Slack does not allow insecure connections, so don’t forget to check this little box.
  7. Pop open the Advanced options section of the IRCCloud form. In the Commands to run on connect field, enter the following:

    AUTH $USERNAME $PASSWORD

    where $USERNAME and $PASSWORD are the values from the associated fields from your Slack team Gateways page.

  8. Enter the $PASSWORD value from the Slack team Gateways page (the same value you used in the previous step), in the Server password field on the IRCCloud form.
  9. Click Join network on IRCCloud.

That should do the trick.

Posted on

Announcing “Forge Your Future With Open Source”: The first book to detail how to contribute to open source projects

Ever wanted to contribute to free and open source software but didn’t know how? You’re in luck! There’s now a book on the subject, and I’m honored to be its author.

It all started in Spring 2017 when I received a message from my friend (and now editor!), Brian: “Hey, did you know there isn’t a book on how to contribute to open source?”

I’d just left HPE to start freelancing, so the timing was good for me to take on this big project as well. Writing was slowed a little by my busy travel schedule, but now we’re finally ready to share the book with the world.

Q: When will it be available?
A: The beta eBook is available RIGHT NOW. We anticipate the hard copy will be out in June.

Q: Beta eBook? What’s that?
A: Beta eBooks are early releases. These books are works-in-progress, but when released have more than enough content to be useful. People who buy the beta book will receive frequent updates as new content is added and also receive the final ebook when that’s available. Beta purchasers also get the chance to provide feedback on the book before it’s released in hard copy.

Q: Why Pragmatic Bookshelf?
A: Partly because they asked me, but mostly because it gave me the chance to work with my friend Brian. However after working with the Pragmatic team for a few months now I see they’re all just as great as Brian is, so I’m happy to be a member of the Pragmatic author family.

Q: There’s probably a reason this book wasn’t written before now, you know.
A: Yes: A lot of experienced open source contributors get the “I did it the hard way, and so should you, kid” chip on their shoulder and can’t seem to lose it. That’s worked against us for decades, as thousands of potential contributors walked away discouraged.

Q: OK, so, what will you cover? I mean, it’s not like there’s One True Way to contribute.
A: You’re so right! Distilling nearly forty years of free and open source contributions into a single set of best practices that can apply to most projects is a challenge. Thankfully the years I’ve spent as an Open Source Advocate Without Portfolio (helping maintainers and organisers of all projects) makes this possible. The book covers the background and history of free and open source, tribal knowledge that trips up new contributors, how to find a project to contribute to, how to contribute for your job, and so much more.

Very importantly, THIS BOOK DOES NOT FOCUS SOLELY ON PROGRAMMING CONTRIBUTIONS. Instead, it addresses documentation, design, and all forms of contributing (including, of course, programming). There’s room (and a need for) everyone in free and open source software.

You should definitely go buy it now then leave feedback which will help improve it for future readers. You’ll be a part of what makes free and open source so great.

Posted on

The OpenStack identity crisis


Does OpenStack have an identity crisis? I think it does, and solving it will help the project establish itself in the minds of infrastructure deciders.

I spent two years working with a team primarily dedicated to OpenStack development and thanks to that had the opportunity to attend several Summits as well as observe multiple OpenStack project communities.

What I learned is that if you ask ten Stackers, “What is OpenStack?” you’ll receive ten different answers. Even in discussions with members of the OpenStack TC, I was never able to get a consistent answer to what ought to be a very simple question.

OpenStack has an identity crisis. It doesn’t appear to know what it is, or for whom. I feel this was exacerbated by the Big Tent initiative, which was well-considered and -intentioned, but in the end just muddied the waters of what it meant to be “OpenStack.”

Recently the OpenStack Foundation announced that it’s leaving the Big Tent in its rearview mirror. Perhaps this is the turning point? By moving on from the Big Tent experiment, OpenStack is now free to define what it means to be, well, OpenStack. Establishing a consistent identity and branding across this very large project will help it regain the momentum it’s been losing as several of its now-former marquee corporate members withdraw from their public cloud attempts and the OpenStack Innovation Center.

Unfortunately, the OpenStack Foundation may not take this opportunity. Instead, it appears that rather than pause to define what it means to be OpenStack, it’s considering opening the Foundation to other projects. The logic here appears to be that any technology in the “stack” can be “open,” so why shouldn’t that technology live under the umbrella of the OpenStack Foundation?

Is the OpenStack Foundation simply upgrading from the Big Tent to the Really Actually Quite Massive Tent? If the Big Tent muddied the waters of OpenStack identity, then this has the potential to convert it to opaque sludge. Without a very firm grasp on what it means to be OpenStack: The Project, how will the Foundation be able to distinguish between what’s an OpenStack Project and what’s merely an open stack project?

As well, this feels like a bit of a land grab. In the past few years the Linux Foundation (and especially its subsidiary the Cloud Native Computing Foundation) has been growing by leaps and bounds, bringing projects into its auspices nearly every week. Having apparently thrown off the limitation of tending for merely Linux business interests, the Linux Foundation now wardens dozens of open source projects, as well as bringing on dozens of new member companies. The Linux Foundation is now doing quite well, largely due to this expansion. Did the OpenStack Foundation look to LF and think, “Well, if it worked for them…”? Is this OpenStack’s move to regain relevancy and mindshare as big name member companies (such as IBM and HPE) pull away from their OpenStack-driven initiatives, throwing their support elsewhere in the infrastructure ecosystem?

Whatever the reason, it appears the OpenStack Foundation is still only considering welcoming other open stack projects into its membership. Hopefully before they do that they’ll pause for however long it takes not only to define what it means to be OpenStack in this post-Big-Tent world, but also to communicate that to all of its existing contributors, operators, and member organisations. The next time someone asks ten Stackers, “What is OpenStack?” it would be great to receive a single answer.

Posted on

Jump-start your career with open source skills

Not Another Jump Shot by pinkcotton on Flickr, CC BY-NC-ND Although attending college is not required for success in software development, college programs can provide a great deal of useful information in a relatively short period of time. More importantly, they are designed to cover all necessary concepts without the knowledge holes some self-taught practitioners suffer. College programs also often include theory and history, which can form the foundation for professional exploration and decision-making.

Yet college graduates entering the workforce often find their coursework has emphasized theory over the practice, technologies, and trends required for success on the job. The reason? Curricula take time to develop, so institutions of higher education often teach technologies and practices that are at the tail end of current usage.

Internships

Fortunately, there are ways to learn and develop the knowledge and skills you need to land a job and succeed in today’s workplace. One approach is the internship. Many students spend mid-term breaks interning with organizations. Internships are an effective way to gain exposure to different technologies and techniques than those taught in school. An added bonus: you’ll get paid to do so (do not accept an unpaid internship; your time is valuable).

Of course, competition for the best internships can be stiff, and it might be difficult to find an internship in the area or industry that most interests you. Also, don’t expect to intern on your schedule; you’ll likely spend the holiday working rather than relaxing and spending time with family and friends. Consider it the trade-off for gaining experience that will give you a leg up when you start your career.

Contributing to open source projects

Another way to gain extra knowledge is to participate in, and contribute to, free and open source software (aka FOSS). There are millions of FOSS projects that offer a nearly infinite variety of learning opportunities. It’s a superb way to learn critical skills you may not get in school, such as QA, version control, writing tests, using continuous integration and development, writing documentation, and designing user interfaces. You can participate in FOSS on your own schedule, any time of the year. FOSS participation offers the opportunity to learn from, and be mentored by, some of the best and the brightest in the industry. It also allows you to build a portfolio of publicly available work, which will impress prospective employers much more than standard coursework.

Finding an internship can be as easy as visiting your college’s career and employment office. But how do you find a FOSS project to contribute to?

Finding a project

Several online services are available to help people contribute to free and open source software. Some provide tips for contributing, while others act as matchmakers, pairing people with projects that need help. First Timers Only, in addition to being a movement requesting and helping project maintainers label bugs as #first-timers-only, presents new contributors with helpful links and tips to get started. GitHub Explore and CodeTriage both provide pointers to interesting projects that are looking for new contributors. During the Christmas holiday season, 24 Pull Requests is a great way to find projects that need help.

Your search for FOSS projects needn’t be limited to online. Most urban areas and many smaller communities play host to different events where you can learn and contribute in person. Many groups post their events, conferences, and hackathons on Meetup.com or even on Facebook, but don’t forget that your local public or college library is a valuable resource to learn about events in your community. If you can’t find a group, start one! The library is also a great place to post meetings and bring together people who wish to explore open source contributions.

New contributor-friendly projects

Some projects are known to be particularly friendly and helpful to new contributors. What follows is far from a complete list:

Finally, keep in mind that free and open source software needs programmers, but it also needs designers, writers, marketers, and more! Developing and supporting FOSS is truly a multidisciplinary undertaking. Whatever you do, and wherever you wish to take your career, free and open source software can help you learn what you need to be successful and competitive in the job market.

Originally posted at opensource.com

Posted on

Concerns about the Community Data License Agreement (CDLA) initiative

xkcd on Standards: https://xkcd.com/927/

This week The Linux Foundation announced the new Community Data License Agreement licenses. I have not yet read the licenses themselves, as I’m still digging out from attending yet another amazing All Things Open, but even without knowing the contents of the licenses I have some questions and concerns.

Jim Zemlin, Executive Director of The Linux Foundation, is quoted in the CDLA press release as saying:

“An open data license is essential for the frictionless sharing of the data that powers both critical technologies and societal benefits…”

Well stated! Open licences for software, data, and other creative works are more important than ever for powering the innovation and invention that move us forward as an expanding civil society. They enable collaboration, without which we’d each be stuck in our own silos, continually reinventing the wheel.

What confuses me, however, is why The Linux Foundation decided to go its own direction rather than support and enhance the well established and understood Creative Commons licenses. There is no mention in the press release that other open data license options already exist, let alone whether they may have some shortcomings that the CDLA is intended to address. But those licenses do exist already, and their use is well documented and accepted by institutions worldwide. Does The Linux Foundation object to these licenses in some way that they created their own? Why fracture the data licensing space in this way?

In fact, Andy Updegrove, in a blog post welcoming CDLA into the world, stated that part of the motivation for its creation was specifically to avoid the license proliferation that plagued the early years of free and open source software and that was (and is) admirably curtailed by Open Source Initiative, its Open Source Definition, and its list of OSI-Approved licenses. By creating their own open data licenses instead of throwing their considerable weight behind the existing Creative Commons licenses, isn’t The Linux Foundation contributing to the license proliferation Updegrove says they’re trying to avoid?

That’s one concern I have with this announcement. The other is related to the source and warden of this new initiative.

The Linux Foundation is registered as a 501(c)(6) non-profit organisation. Colloquially known as a c6, these non-profit organisations are formed to promote shared business interests and are beholden to their members (typically businesses or business people themselves) to do just that. In the case of The Linux Foundation, it was originally formed to promote Linux in the business and enterprise space. It has done that brilliantly, and Linux is now the default operating system in servers, automotive, embedded devices, and just about anything else you can think of (save desktops, where it still has a long way to go).

The CDLA, however, claims it is not solely for businesses:

The CDLA licenses are designed to help governments, academic institutions, businesses and other organizations open up and share data, with the goal of creating communities that curate and share data openly.

While I wholeheartedly support the mission of helping governments, academic institutions, and other organisations open up and share data, I believe these institutions would be better served were the initiative brought by an organisation that is accountable to more than simply its members and their business interests. The Linux Foundation undoubtedly has the best intentions here. I do not question that. I do, however, question having the open data of governments and academic institutions being promoted by a group that by definition must dedicate itself to business interests. While undoubtedly The Linux Foundation would not intend to do so, as a c6 there is a risk that the business interests they are pledged to promote might influence the evolution and application of the CDLA licenses.

The optics of the CDLA initiative would be greatly improved were it instead managed by a 501(c)(3) non-profit. c3 non-profits have no accountability to business interests and instead operate solely for the public good (for, admittedly, very large values of both “public” and “good”). For instance, Creative Commons is a c3. Its mission and vision directly support the open sharing of data from government and academic institutions, as well as businesses, independent researchers, and any other data source:

Creative Commons develops, supports, and stewards legal and technical infrastructure that maximizes digital creativity, sharing, and innovation.

Our vision is nothing less than realizing the full potential of the Internet — universal access to research and education, full participation in culture — to drive a new era of development, growth, and productivity.

Again, I find myself confused why The Linux Foundation felt it necessary to proliferate open data licenses in this way. Hopefully more information and statements are forthcoming to explain their fractionalising move.

Posted on

Google, can we talk?

The following is an edited screenshot of my Google Account profile:

My Google account profile

Google, my dear, do you see all of those email addresses listed there? Each and every one of them was not only added to my profile by me, I also took the time to verify with you that each of them is really, honestly, and truly mine and that I wanted them associated with my Google account. You know they’re associated with my account. I know they’re associated with my account. We are in blessed agreement on this point.

Google, my love, you are amazing. You can take my search terms and return a billion results plus relevant advertisements in a blink of an eye. Truly, you are the pinnacle of data association and retrieval.

Google, my pet, so why is it when someone sends me a Google Docs invitation–to one of those emails which we agree are associated with my Google account, by the way–why is it you won’t allow me to access the doc despite my being logged into my Google account? Why are you incapable of performing the (as appears from your users’ perspective) relatively simple lookup to confirm that the address to which the invite was sent is in fact associated with the account which is logged in? Why can you not also do that in the blink of an eye?

Google, my beloved, you have had a very long time to fix this very irritating and, to be honest, quite large usability bug. What’s the hold up? Frankly, people are saying some rather unsavoury things about you. Things like, “Google is an advertising company, not a product company, and therefore it doesn’t care about its users or usability.” Is that true, Google?

Because Google, my sweet, it certainly seems that way from where I’m sitting.

Thanks for the talk. I hope it helped you, because you’re certainly not helping me right now.