Challenges and opportunities for open-source in Silicon — Part 3
In Part 2, we took a necessary detour in order to recognize the Linux kernel as an open source success story as well as trying to understand the most likely mechanisms by which it became a success. The relevance of the Linux kernel is that it is a low-level, central, ubiquitous, reliable, and trusted software component. This is in fact the goal of any production-quality silicon hardware component (open source or otherwise).
In this post I will get into the guts of what open source in silicon actually means, and what it does not mean. This will establish the ground truths for the challenges and opportunities as well as hopefully demystifying some misconceptions. This post is a bit longer than the usual, but it is ground that needs to be covered.
Open-source does not mean “free”
Open-source means “free stuff”, right? Not so fast. More astute observers would articulate that “free” refers to freedom, but even this is not always completely the case (more on this in a bit).
People-time is the most precious and valuable. People-time constitutes the dominant share of cost for any software or hardware development project.
As highlighted in Part 2, the bulk of contribution to the Linux kernel is from private enterprise. These people’s time is far from free. Any development-of, contribution-to or usage-of an open-source project constitutes people-time.
When we talk about silicon, besides the people-time, we must also account for tooling cost. It takes a lot of tools to attain industrial-grade quality for silicon RTL components. Today, many of the most critical tools are neither open source nor free-to-license. This challenge is not unique to open-source related development.
Open-source does not mean “free to use as you please”
(Disclaimer: This section informally deals with legal things. My aim is to paint in broad brushstrokes with the intent to give some perspective, not legal advice. Always make sure to consult with your legal counsel for any questions regarding IP licensing.)
A minimalistic definition for open-source would be to say that the source-code of some intellectual property (IP) is fully observable. This alone has value, but open-source does not imply any specific licensing model. Licensing in a nutshell, defines the terms of an agreement regarding the “usage rights” of the IP.
In Part 2, I discussed the success of the Linux kernel. GNU/Linux (the OS), is licensed under the GNU Public License (GPL). This license allows usage, derivation and distribution but requires a open-sourcing and granting the same license for derivate works.
This makes the license somewhat viral.
What makes sense for an operating system may not necessarily make sense for silicon IPs.
Another popular licensing framework is Apache 2.0 which became popular because it is non-viral. This is the license agreement my team is using to share machine-learning models for the purposes of benchmarking low-power embedded AI-capable silicon (https://github.com/SiliconLabs/platform_ml_models)
Related to Apache 2.0, Solderpad Hardware License is another non-viral framework which has emerged in the open-source hardware realm. The OpenHW group has in fact adopted this license agreement for its open-source silicon IP cores (more on OpenHW group in the next post!).
Also, notable is the CERN open hardware license (OHL), which is interesting in that it provides a three-tier variant of reciprocity level (permissive, weak and strong).
In summary:
- Just because you can “observe” source code, it does not imply your rights to use it, create derivative works thereof or re-distribute it.
- Licensing can be a complicated topic, and modern open-source projects (including open-source silicon IPs) are tending to adopt non-viral agreements, because the less complicated an agreement is, the more likely people will use the IP and even more importantly, the better the IP will become (this is the property of traction).
Governance, not the wild west
Casual observers may view open-source as some sort chaotic wild-west landscape. Nothing could be further from reality. The most chaotic developments I have ever experienced have been on closed-source internal projects. If you have been around technology for a while, I am sure you also have a story or two.
Open-source projects tend to be distributed. Distributed in development, distributed in testing, and distributed in terms of goals and motivations. Coordinating this level of distribution and diversity requires very well-defined governance models and practices. Such practices actually create conditions which drive high quality.
Governance of open-source projects spans various mechanisms and control points. For now, let us just consider the lowest-level control points such as code acceptance. As alluded to in Part 2, the acceptance of changes is usually left to a few who have been assigned merit by the collective resulting from observed excellence. These are the people that can be trusted to represent the aggregate needs and desires of the project. These people are known as the committers.
Open-source projects which use GitHub for example, have every “pull-request” carefully analyzed, reviewed and tested before they are merged by a committer. For silicon RTL based projects, this bar can be very high, likely higher than a commit to a company-internal repository.
In many ways, open-source projects are held to a higher bar than traditional closed-source developments. Open-source provides transparency at the source-code level. In addition to this, documented decisions, email discussions and even meeting minutes are publicly available.
Being so in-the-open provides little cover for incompetence or bad actors.
Shame-avoidance can be quite a motivator for upping one’s game. Notice how similar forces exist in sports and entertainment.
Distributed, yet local
Successful open-source projects are distributed. The sharing of the development burden implies a variety of contributors who are likely distributed.
Software inherently will always be a larger codebase than silicon hardware (RTL).
This is an advantage for silicon open-source.
Any individual IP project will likely require a relatively small group of developers but hopefully a much larger group of testers and users.
Even though development may be distributed, this distribution will happen over time. At any given point in time, the RTL code is likely only being modified by one or two groups of people, perhaps working on a specific feature or generation of the IP for some interval of time.
For example, company-A works on a version of an IP followed by company-B, but everything is observable and testable by companies A-Z.
This creates a pattern which tends to be localized development in the short term and distributed development in the long term.
Timing
In Part 2, I discussed how the lack of deadlines was one of the key reasons the Linux kernel was successful. Take a deep breath because this statement need a little un-packing with a focus on silicon.
Silicon development, especially at the full chip-level tends to follow a classic waterfall scheduling approach. If you have good technical marketing people and system architects, you get your “BRUF” (Big Requirements Up Front), the architects generate the architecture (possibly simulating it in some higher level language), and a milestone-based schedule is formed, executed upon and tracked. Unexpected things show up and a cross-functional project team “manages” these things. Likely within this waterfall, there are loops of various bandwidths resulting from iterations/adjustments.
This is not the way open-source silicon development can operate, at least not at the “macro” level. There is usually no “project manager” and
there is no way to demand time or timeliness from contributors.
This leads me to the following observations and advice:
- Open-source silicon development projects should aim to leverage certain principles of agile such as always being close to a state of readiness (production-quality RTL) within a reasonable time-interval from a merged new feature or change. For example, the Linux kernel can be released every ten or so weeks even with major changes. RTL developments (which involve much less code), should be able to do much better. Such frameworks make it easier to attract and enable contributors because it lowers the bar to entry and enables contributors to easily add value.
- Chip-developments (as clients of an open-source project) should not try to align their project schedule to an open-source silicon-component development which is not in an already continuously releasable state. In other words, if the open-source development is following waterfall and that schedule overlaps with your chip schedule, run away and come back later, or better yet, see if you can help transform the project to become more iterate-able.
- Short of very focused yet distributed collaborations (which I have witnessed in real life — yet not the norm), one cannot make any specific assumptions about the timing of open-source project developments. Clients of open-source projects should thus strive to take stable known releases, and if they really need something new done, the best way is to actually help get it done by providing people-time.
- Lack of deadlines in open-source allow the project as a whole to be more focused on building the best solution. Passive clients of such projects need to carefully select appropriate intercept-points and not have any expectations on timing. Active or “demanding” clients should become contributors. Contribution helps with building up influence in an open-source project. This is the primary mechanism which brings individual excellence and can thus result in active clients having not just influence but committer-level control. Such contribution and control gives an active client the ability to heavily influence the timing of features. This is a somewhat long-winded way of saying that,
if you want something done now, bring excellent people to contribute and make that thing happen.
What’s Next?
In the next set of posts we’ll continue to dig deeper as well as looking at concrete examples of modern open-source RTL silicon projects.
