The X.org Foundation is a non-profit governance entity charged with overseeing core components of the open source graphics community. X.org had been structured as a legal (non-profit) corporate entity registered in the state of Delaware for some years, which provided tax deduction on donations and other such benefits.
Unfortunately, being a non-profit is not cheap and entails various administrative tasks – filing annual reports, maintaining a bank account, dealing with donations and expenses, and so on – so the overhead of being an independent non-profit was deemed not worth the benefits, and in 2016 the members voted to join Software in the Public Interest (SPI). Joining SPI made a lot of sense; primarily, it would relieve X.org of administrative burdens while preserving the benefits of non-profit status. The costs of being in SPI are offset by the savings of not having to pay the various fees required to upkeep the corporate entity ourselves.
In that 2016 vote, I was elected to a position on the board to serve in the role of treasurer. I took on the tasks of establishing our financial services with SPI and closing down our Delaware registration. These seemingly straightforward administrative tasks proved to turn into a much more involved ordeal.
The Challenges of Dissolving a Non-Profit
Initiating things with SPI was complicated by the fact that I was new to the board, as well as the usual response delay endemic with volunteer-driven efforts. With some email back-and-forthing, we were added to SPI’s website, established an X.org “Click&Pledge” bucket for credit card donations, and later established Paypal donations as well.
The X.org Foundation’s cash assets were held in a Bank of America (BofA) account registered under the name of a previous treasurer. Unfortunately, BofA’s security policies meant that only the old treasurer could close out the account; fortunately, he was still available and able to do this. A lesson learned for other non-profits would be to ensure multiple people are registered for the organization’s bank accounts.
Once the assets were transferred it was time to close down the foundation itself, or “dissolution” in corporate terms. Delaware had a byzantine array of forms, fees, and procedures, and with this all being completely foreign to my experience, mistakes were inevitable. They kindly provide PDFs with fillable fields, however while some forms can be filed online, the PDFs have to be printed out and sent by mail. I was confused on this point and sent the filled in PDF to them online; unfortunately their system’s PDF processing system doesn’t support fillable fields and strips them out, resulting in invalid submissions.
Another lesson I learned is that the Division of Corporations does not notify you in case of errors, so I did not discern the failure for months and it took a number of phone calls to identify the problems and correct them. What brought the failure to my attention was when we attempted to terminate services with our registered agent. I’m still not exactly sure what a registered agent is, but corporate registration in Delaware requires it. X.org had a contract with National Registered Agents, Inc., who (once I’d squared away the dissolution paperwork) were pleasant to work with to close out our account with them.
It’s hard not to think of this transition as the end of one era and the beginning of another, and I’m very optimistic about the new capacity that the X.org Foundation has via SPI for receiving and processing donations. We’re now well positioned for organizing fund-raising activities to support X.org’s events and student sponsorships, and hopefully the information provided in this article will be beneficial to other open source communities facing similar problems.
The RTSP 2.0 was proposed in December 2016 to replace the 1.0 version of the standard; this new version is not backward compatible with the previous one. RTSP 1.0 is almost 20 years old, and it’s done a good job at defining a standard protocol for real time media streaming signaling, but it has not evolved much since then and had some issues that were worth fixing. The new version of this standard aims to resolve inconsistencies, clean up the RFC, add missing definitions, and restructure the document to reach better interoperability between implementers. RTSP 2.0 also comes with a bunch of new features (such as pipelined setup request, to avoid round trip time on initialization) and removes some features that were considered not useful enough (such as the RECORD command).
GStreamer’s RSTP 2.0 Implementation
At Samsung, we decided it was the right time to introduce the very first implementation, and we’ve now readied support for the new RSTP 2.0 protocol. This work has led to a set of patches that have been proposed in the upstream GStreamer project!
This article will explore how OSS can benefit a business from a non-technical perspective.
Open Source Development Reduces Costs
One of the major reasons more companies are adopting OSS is because it is a very effective way to reduce development costs. The two primary ways open source reduces development costs is by simplifying software licensing and increasing development speed.
Initially, the most obvious place OSS reduces costs is through the complete lack of licensing costs. Proprietary software typically includes initial licensing costs and ongoing maintenance contracts that can be a significant portion of the initial costs; these are often unavoidable. OSS licenses grant free use, modification, and distribution rights to everyone, meaning there is no initial costs to licensing the software, and maintenance can be customized to the needs of the specific business.
OSS also has a lower cost associated with the software procurement process since the OSS can simply be downloaded for experimentation or research, with no requirement to negotiate procurement with a proprietary vendor. Finally, OSS licenses allow a much broader range of use and customization, sometimes unlimited, this usually needs to be negotiated in a contract with a vendor in the case of proprietary software.
Increases Development Speed
In an OSS project, code functionality can be modified whenever necessary, with no need to negotiate custom contracts or statements of work with third-parties; this alone can result in significant improvements to development speed and reduce the amount of time to deploy products or services.
Any contributions that are successfully committed upstream will ultimately reduce the amount of effort required for ongoing maintenance. Once a maintainer has deemed code worthy of being included upstream, they usually do so with the implicit understanding they will maintain its functionality in the project unless something else is specifically agreed upon. Of course, there are limits to this, and the maintainer may eventually decided the functionality doesn’t comply with project requirements in the future; this may result in the code being dropped if no contributors step up to maintain its place in the source code.
Additionally, open source communities typically produce a faster evolution of upstream software that’s based on the features the community needs rather than financial motivations. The release early, release often strategy of most open source communities results in regular updates that allow anyone to take advantage of new features as soon as they’re available while also monitoring changes to experimental versions to be prepare downstream software to accommodate upcoming changes to stable versions.
The Strategic Value of Open Source
OSS has value that goes beyond the company’s bottom line; it can also be an effective route for creating strategic value. The two major ways it accomplishes this is through an avoidance of vendor lock-in and the ability to influence the direction of vital software through technical and political leadership.
Avoid Vendor Lock-in
A proprietary vendor might limit their software’s compatibility with competing services to elevate their prices. This can lead to any companies who rely on this software to face extremely high costs to migrate away from proprietary software which puts them at a disadvantage in contract negotiations.
OSS development encourages compatibility with more formats and software because it improves the functionality of the software: the primary goal of the developer community. Additionally, the ease of adaptability to niche use cases tends to make OSS compatible with a much wider range of complimentary software.
The primary benefit of this is that it mitigates the risk of upstream software discontinuation. Proprietary software vendors might discontinue a product, get purchased by another company with different business motivations, or go entirely out of business. Any of these scenarios can result in a sudden and expensive switch to new software.
On the other hand, OSS code is not generally owned by any single organization or individual, and anyone can pick up the reins to keep the project going. While this sudden changes in leadership for an OSS community still have costs for companies that rely on the code, adopters will have more options and flexibility for dealing with these changes. For example, an affected company could decide to adapt to the new direction of the project, or fork the project if the new direction conflicts with the company’s requirements.
Create Technical and Political Leadership
Open source community leadership provides an avenue to ensure important software remains viable to a company, while also ensuring the they have a voice in community decisions.
Open source leadership must be earned through an ongoing participation in the community, and is something that can be lost due to a lack of participation. Achieving OSS leadership takes persistent effort over an extended period of time, but the benefits often outweigh the costs. Typical reasons to go through this process include a desire for improved visibility in external developer and user groups, and gaining technical influence over the direction of important projects.
A major benefit of open source leadership is that it can be leveraged to grow internal open source competence by promoting open source best practices and transferring knowledge of open source components to internal teams. Finally, engineers who dedicate time to upstream contributions improve the ability of product teams to use open source, making it easier for them to directly maintain and improve the OSS components they rely on.
The Rosy View of Open Source
After reading the last two articles in this series, you might think OSS is nothing but sunshine and flowers with all the benefits it offers. These benefits might be pretty big, but they also come with significant risks and obligations any company that uses OSS needs to be aware of. The next article in this series will cover these risks and obligations.
The Tizen Developer Conference (TDC) is just around the corner; it will be held May 16 – 17 at the Hilton Union Square Hotel in San Francisco, CA. Our team contributes a ton of code to some of the critical open source software that makes up Tizen, so of course we’ll be spending some time there to network with app developers and device makers who work with Tizen.
What’s Happening with Tizen?
There has been quite a few exciting developments for Tizen over the last year; for starters Samsung joined forces with Microsoft to bring .NET to Tizen, allowing developers to build applications for Tizen using C# and Visual Studio. Additionally, Tizen has continued to show up on a growing number of consumer devices including the Gear S3, Z2, Gear 360, AR9500M air conditioner, POWERbot VR7000, multiple smart TV’s, and more. Finally, Tizen RT was released last year, making it easier than ever to run Tizen on low-end devices with constrained memory requirements. All of these changes create a great environment to see some interesting new things at this conference.
These developments have made Tizen more accessible than ever for app developers and device manufacturers; now is a great time to get more deeply involved in this ecosystem. Take a look at the conference sponsors page to get an idea of what companies will be at TDC to show off their latest work.
What to Expect at a Tizen Event
TDC is a technical conference for Tizen developers, app developers, open source enthusiasts, platform designers, IoT device manufacturers, hardware and software vendors, ISVs, operators, OEMs, and anyone engaged in the Tizen ecosystem. It offers an excellent opportunity to learn from leading Tizen experts and expand your understanding of mobile, IoT, wearable tech, and IVI systems engineering and application development; events like this are the best way to network with the top companies working within the Tizen ecosystem.
Not to mention, Tizen events often include the unveiling of new devices, so visitors get to be some of the first people in the world to see the next greatest things for Tizen. The real cherry on top are the giveaways that accompany some of these announcements. Winning a new device more than makes up for the cost of admission :-)
Last but not least, the most valuable component of these events are the technical sessions that provide practical knowledge to help build better devices and apps. There are four session tracks to choose from:
Device Ecosystem – Learn how to create new devices with Tizen.
Application Ecosystem – Learn how to build apps for Tizen with .NET, Xamarin.Forms, Visual Studio, and more.
Platform Core – Learn about some of the platform components that make Tizen great for various use cases.
Product Experience – Learn about some of the interesting Tizen features that are being used to make products better.
TDC will conclude with an IoT hands-on lab that will provide training for using Tizen RT and ARTIK devices to build IoT products. This requires separate registration, so make sure to bring your laptop and coding skills so can take part in this wonderful opportunity to learn from experts.
Time is running out to plan your trip to this conference. Students can register for free (don’t forget your student ID when you come), and for everyone else, you can use the coupon code TIZSDP to get 50% off your registration fee. If you’ll be in the San Francisco area on May 16 and 17, don’t miss out on this great opportunity. Check out the registration page to learn more about attending this conference.
In case you haven’t heard the news, we’re currently on a quest to hire a new Linux Kernel engineer, so we thought this would be a good time to explain what our team does for Samsung. Samsung relies on open source software for the vast majority of products and services the company produces and as a result, it has become an imperative for the company to have a team dedicated to improving and leveraging open source software.
Essentially, the OSG has two primary purposes. The first is to provide open source leadership within Samsung by helping other divisions in the company understand how to participate in and benefit from open source development. The second is to serve as Samsung’s representatives in the wider open source community. The mandate of this team is to focus on enhancing key open source projects and technologies via active contributions to them, and to be actively involved and engaged with various open source organizations and foundations.
What Does it Take to be an Open Source Engineer?
The engineers on our team spend most of their time engaged in normal software development, that is designing, developing, debugging, and testing as they improve functionality in key open source projects. However, their skills often go far beyond their technical capabilities because they also have to be a bridge between Samsung and the open source communities we rely on. This means they often engage in
Supporting product and R&D teams with their open source expertise,
Conducting internal workshops to build open source competencies in diverse business units,
Promoting best practices for open source within Samsung,
Monitoring Samsung software architecture to identify components that can better leverage open source technology,
introducing new and innovative open source technologies to Samsung,
Representing Samsung in the wider open source community at external conferences and community events and through technical and political leadership roles.
Our team has a unique combination of technical, interpersonal, and theoretical knowledge and skills that they have to rely on every single day to adapt quickly to changes in open source technology.
If you’re someone who has successfully contributed code to the upstream Linux kernel, and you think you’d be a good fit for our team, we’d love to hear from you!
Technical value is one of the most important traits of software development and engineering. A mature open source community will often have multiple companies, organizations, and individuals who contribute to and depend on the code base. Any groups that depend on the code are invested in the future of the code, making it much less likely for the code to disappear while simultaneously encouraging participants to play an active role in ensuring proper bug and security fixing processes. This article will explore the ways open source software can benefit a business from a technical perspective by offering improved code stability and greater control over the software stack.
Open Source Improves Code Stability
Software built by a proprietary component provider can typically only be fixed by employees of the vendor company. In an open source community, anyone can test or fix bugs, regardless of association, and contribute to the reporting and tracking of bug fixes; as a result, there are many more avenues for errors in open source code to be discovered. This concept forms the core of Linus’s Law: “given enough eyeballs, all bugs are shallow.” Essentially, this states that when there are more tester’s and developers working together, bugs should be identified more quickly with more people who are capable of addressing them.
Anyone who identifies a bug with open source software can either fix it themselves, or inform the community of the problem in hopes that it will be fixed by someone who has a common interest. Proprietary vendors make commercial and financial evaluations before they implement security or bug fixes; there might not be enough financial incentive for them to make the specific fixes you require and creating this incentive can be extremely costly. Bugs in proprietary code can typically only be found through indirect methods, such as by encountering them while using the code in another product or service. On the other hand, OSS can be evaluated directly which makes it possible to find bugs before the software is even used.
The benefits of OSS for security are much more challenging to completely evaluate because open source vulnerabilities are often highly publicized, whereas proprietary software vendors can rely on security through obscurity since they distribute object code rather than source code. Because of this, bugs and security issues tend to be addressed much more quickly in open source communities with one major caveat: it hinges on the community having adequate bug and security vulnerability reporting and patching practices. There have been multiple high profile security vulnerabilities in OSS, including Heartbleed, which went unnoticed for years as it was deployed in numerous systems all over the world. In recent years, the security practices of OSS have come under much more scrutiny, resulting in the formation of groups like the Core Infrastructure Initiative, which seeks to identify critical open source components and ensure security is given adequate attention.
Ultimately, proper bug fixing and security practices come down to human ability and processes. Proper bug fixing and security auditing processes in an open source community can create code that is exceptionally secure and the high level of transparency open source offers makes it possible to evaluate the community directly. Many communities have formally defined processes for identify bug fixes or security flaws and patching them, all of this can be verified externally which isn’t possible with proprietary software. Finally, all OSS can be built from source code which improves security in cases where object code distribution is a concern.
Open Source Improves Control of the Software Stack
Another major technical benefit of OSS is having improved control of the software stack by means of a relatively unlimited potential for customization, and better knowledge-base of resources and information. Proprietary vendors can restrict the customization of their software and require expensive contracts for customization services. On the other hand, integrators can adapt OSS to meet the needs of anyone.
Mature open source communities often have numerous experts who can be relied upon for customization, whether it be through volunteered effort as a result of a shared interest, or by being hired directly to make the customizations. Since anyone can acquire OSS for learning purposes, there tends to be a much more broad and diverse ecosystem of developers and engineers. Additionally, since open source code is typically built in a modular fashion and governed through a maintainership system, it’s often much easier to find the items that need to be tweaked in the code and to make the required modifications.
One specific example where OSS is much more customizable than proprietary software is in language translations. Since all code is open to the public, anyone who is capable of translating between two languages can adapt the software for their specific language. This allows OSS to be translated to niche languages that might not be cost effective for a proprietary software vendor.
One final way that OSS improves control of the software stack is in the availability of a detailed knowledge-base of information. Proprietary vendors can restrict learning resources for their software however they want, but OSS tends to have a much more robust selection of supporting knowledge material that can be used to build in-house expertise. These resources can include things like wikis, project websites, and forums that provide general information for users and developers, as well as resources that allow individuals to get into direct contact with project experts like mailing lists, chat rooms, and question boards.
Leveraging the Technical Benefits of Open Source
This article should have explained some common technical justifications for why OSS often provides better flexibility than proprietary software. In summary, it provides product creators:
The freedom to fix any bugs or security flaws that are identified,
A transparent process for identifying and fixing bugs and security flaws that can be verified externally,
More options for customization, with a more diverse ecosystem of developers and users, and
An improved knowledge-base that is publicly accessible.
The next article in this series will explore the ways OSS can benefit a business by simplifying licensing, increasing development speed, and reducing vendor lock-in.
Open source compliance is often overlooked, but is a critical component of a successful open source software strategy. If your company is going to use or contribute to open source software, failure to comply with the software licenses can lead to costly cleanup efforts, or even lawsuits if license violations are found. To mitigate these risks, it’s important to establish an internal organizational program that manages compliance with open source licenses.
For many companies, open source compliance is often the first major step into open source engineering, so it’s vital to establish proper organizations and procedures that build a foundation for continual success. That’s why Ibrahim Haddad joined forces with the Linux Foundation to create Open Source Compliance in the Enterprise, and released it as a free handbook to download.
This book covers the essentials of establishing a successful open source compliance strategy in an enterprise setting, including the structure of an open source management program, common processes and tools for compliance, how to train and encourage developers to follow compliance processes, when and how to involve legal experts, and more. Many of these strategies are employed here at the Samsung Open Source Group and have helped us establish ourselves as a valuable asset to Samsung’s success. If you oversee a team of software engineers who work with open source software, this book will provide a wealth of helpful information; you should give it a read!
After finishing high school, I was destined to continue my academic life studying one of the fine arts I always loved: Architecture. I took special art classes to get prepared to study it, and so I did; I entered the architectural school at my hometown in the Canary Islands.
In their first year, all students learn about the Bauhaus school and their impact. I knew about them, but in that year I learned about their philosophy in detail and I became sanely obsessed with their work. During their difficult social/political time, Bauhaus revolutionized the world of architecture, design, and art. Their modernist designs were centered in functionality, simplicity, rationality, and taking art to everybody through mass production. In summary, making our day to day habitats and tools better, cheaper, simpler, and available to all.
So through most of my first year I asked myself “Where is the present-day Bauhaus?” I was certain to find the contemporary equivalent and join in. My personal drive isn’t to live forever, rather my goal is to create something that will. After searching for months, I couldn’t find any new history-changing movements in architecture or art in general. One day in my second year, I discovered free software through a friend who showed me how valuable a tool Linux can be. Being a computer enthusiast, I knew the term, but not the philosophy behind it; once I learned about it everything clicked: I’d found what I was searching for. The next year of my academic life I started studying Computer Engineering, and the rest… well, simply fell into place.
A few times every century a social changing movement arises; right now, the free software movement and the emergence of open source software in mainstream business and culture is defining our tools and rights in a world rapidly switching from analog to digital. Much like how new ideas introduced during the Bauhaus movement changed the architecture and design industries, open source software and the free software movement are changing how we develop modern technology; I feel very proud and lucky to be a small part of it.
A few days ago, while on my way back from the GStreamer hackfest and conference combo, I tried to come up with a list of pearls to share here and arrived at a pretty troubling conclusion: there was no easy way to do so.
I met Luis (De Bethencourt) a kilometer away from my hotel on a cold Saturday morning on October 8th. By then, I had already figured the only exercise I’d be able to get during my short 4-day stay in Berlin was going to be related to my commute, so I decided to embrace walking. We headed for C-Base as soon as we meet at his hotel’s lobby and arrived 10 minutes later to meet the typical familiar faces from the GStreamer community. So did everything start.
The GStreamer developer community, while quite compact, has a surprisingly large number of regulars; people tend to stay around. This is something you hardly notice from outside the project – not even as a user if you aren’t paying attention – but it’s quite evident if you have been around for a while because you keep running into the same people over and over. Granted, you might not know everyone, but chances are good you will eventually get to meet the new ones. They’re likely going to be around for the next gathering anyways.
The OSG GStreamer team, Luis, Arun, Thibault and myself, had some sort of plan. There were areas we had agreed to work on and for the most part, we did. Everyone had a talk to deliver too and we even had a sprint arranged for Sunday, so it looked like we were off to a busy weekend. The way we work closely resembles the community we work with and there’s no single pair of OSG multimedia engineers living in the same part of the globe. A properly timed face to face can do wonders, and it did. For example, Luis had recently started playing in the management big leagues with his promotion to European team lead and it was the first time we saw him exercising his new role. We can spend 8 hours a day on IRC, but there’s nothing like seeing wildlife in it’s native habitat, and you can’t exactly get that from ASCII alone. Images are necessary.
So what were we working on for the hackfest? Well… Here’s the silver-lining run down.
Arun spent most of his time presenting and gathering feedback on his synchronized/coordinated playback ideas. We have been thinking about quite a few use cases that might benefit greatly from a more established infrastructure in that regard. Additionally, he helped with the changelog wrap-up for this period and an assorted set of other release-related tasks.
Thibault has been putting a lot of thought into enhancing deep run-time inspection, notification and logging. It shouldn’t come as a surprise then, that besides fixing quite a few GStreamer Editing Services bugs, he spent most of the hackfest coordinating with some of the elders on bringing CTF (Common Trace Format) to GStreamer and continued working on his implementation while considering ideas that may ultimately lead to a tighter integration of traces and logs. More on this as HE develops :-)
Luis entertained himself with a set of tasks better presented as a full list:
prep work to write a GStreamer parser element in Rust,
write documentation for the AudioVisualizer Base Class,
port the puzzle (gst-plugins-bad) element to 1.x,
play with the Meson build system and its use for GStreamer,
rebase some Linux kernel work (with mainline) to get it ready to submit for 4.9-rc1,
research the latest work done in v4l2 and,
prepare the OSG Multimedia team sprint.
I worked mostly on digital terrestrial television. Primarily to make sure whatever I was presenting on my Monday talk actually worked in Berlin; a few fixes to the DVB-T supporting code included. I have a signal generator that allows me to test multiple broadcast standards, but there’s nothing like a real-life setup. Relatedly, here’s the channels.conf file for Berlin mitte I came up with while testing. You’re welcome.
And all of a sudden, it was Monday morning.
The conference took place at a venue with a completely different vibe this time around; Betahaus defines itself as a place for idea sharing and it looks the part. There were two main conference rooms, the Arena (where I had to fight Monday after lunch) and the Innospace, which was a bit larger. For the most part, the two parallel tracks had a full attendance, with everyone of the hundred-something GStreamer lovers, haters, or both having a proper place to sit. Drinks and lunch were included and complementary, the latter sponsored by Facebook. The conference had a comparatively large set of corporate sponsors but that’s not unlike every single GStreamer Conference I’ve attended. Did I mention people tend to stay around? Well, companies do too.
The big news came from tpm, aka __tim, and officially Tim-Philipp Müller (everyone’s favorite reviewer), right after some slides with the latest development highlights: the project is going to be backed up with a foundation; some really brief notes on the reasoning behind it and spare details followed. This is a somewhat popular idea, and it makes sense. I think everyone who didn’t know about it was in agreement. Way to go!
Going through each one of the talks would be kind of boring. Not to mention redundant, as they were all recorded by Ubicast (long time GStreamer user and conference partner) and are now available online. For the most part, we got the usual mix of incredibly useful light-training sessions and exposure to new and interesting use-cases and novelties. The topics were well balanced and rounded, and the schedule was followed to the letter, always a plus. Our team had a few appearances in it:
Additionally, Julien Isorce, a Samsung colleague and long-time GStreamer developer, briefly gifted the audience with “Code review in Chromium project + quick update on the Media Process based GStreamer backend”. It’s always great to see Julien and even better to passively pick his brain. Thank you!
Remember I told you right at the beginning how hard was to select what to share from the GST Conference/Hackfest combo-like experience? There’s just too much to process, let alone the overwhelming sense of respect for everyone presenting talks and helping around. It seems almost like any kind of selective process would end up being unfair. I pondered about this for a few minutes while my plane approached home and made a bold choice. If being fair was impossible, I would aim for absolute unfairness and present you with my absolutely arbitrary single pearl of the conference: Lubosz Sarnecki’s Holographic Telecommunication in the Age of Free Software. This VR-focused talk had my attention right from its title and Lubosz delivered to the promise; enthusiastic, complete and even loquacious would be the words I’d use to describe the lecture, but you’d have to see it to understand, and you should.
That was pretty much it. The hackfest went for a weekend, the conference for 2 days and most of the attendees for four to five if you catch my drift. The rest of the world just continued living without paying much attention. Considering we’re a group of developers who enable distraction as part of our work, this might be our very own fault.
To recap briefly, the Board of Directors from both organizations have agreed to consolidate operations under the Open Connectivity Foundation (OCF), while the open source projects will continue to be hosted at the Linux Foundation. I’ve noticed some confusion about what exactly happened, so I thought I would clarify some things in this article.
To start, OCF and the AllSeen Alliance are each non-profit entities that are responsible for the business operations of each project. In addition, OCF hosts development of the specification. Each organization has their own bylaws, membership agreement, IPR policy, and charter. By law they must be governed by a board of directors, which consists of representatives from member organizations.
Following the open source best practice of separating technical governance from non-technical governance, each project has their own hierarchy of decision makers. While the open source projects have representation in OCF and AllSeen Alliance (via a nominated representative), they are separate projects which make their own technical decisions.
On the other hand, AllJoyn and IoTivity are still separate projects at the Linux Foundation. It’s a lot harder to merge two separate codebases than it is two organizations. For the time being, it looks like they will remain separate. This makes good technical sense, as it ensures a stable codebase for security updates to products which are already in the market based upon existing code.
With that said, the stated goal here is convergence. It has been noted elsewhere that many former AllJoyn developers are now working on IoTivity. The goal is to evolve the OCF spec and IoTivity itself to be interoperable and backwards compatible with both. So over time, the expectation is that IoTivity will be the single official reference implementation for the merged effort.
Our hope is that this will lead to a stronger, more stable, diverse community of contributors who will continue to evolve IoTivity into bigger and better things.