The Business Obligations of Open Source Software

This article is a part of a series on using open source in business:

The previous two articles in this series covered the technical and business benefits OSS offers. However, this only paints half the picture. While OSS might be free to use, modify, and distribute, it doesn’t come without effort and risk; if a company isn’t prepared to handle them, they can cause significant headaches down the road. This article will provide an overview of the obligations and risks a company that uses OSS in their products or services must be aware of.

Licensing and Compliance

While OSS has no initial licensing costs, this doesn’t always mean you’re free to use OSS however you want. Open source licenses can impose a range of obligations that must be satisfied whenever code that includes OSS is distributed in a product or service. This can include things like disclosure requirements, specific notifications, and licensing modifications under the same open source license.

At the very least, all businesses need to maintain an accurate inventory of all OSS that’s used in their products or services, and must have adequate processes to ensure compliance with all licenses both during and after product distribution. Typically, a single person is assigned the responsibility of being the open source compliance manager to oversee the execution of this, and it requires coordination between legal, engineering, human resources, and the compliance officer; larger companies often need to establish an Open Source Review Board to facilitate this coordination.

The most critical coordination is between product, engineering, and management teams: they must identify all OSS used in product code and to assist with any licensing or compliance questions. This often means employee roles need to be expanded to cover the various elements of OSS compliance that directly relate to each position. This coordination must also expand outside the company to include software providers as well because any OSS that’s included in the software they provide must also be properly accounted for and complied with. While establishing a framework for this coordination, it’s common to come across areas that need better tooling which creates more need for deployment and training.

Open source licensing can create substantial obligations, especially in larger organizations, and these obligations require more coordination between various teams. This article only briefly touches on the subject of open source compliance, and if you’re interested in this subject more there is a lot of detailed information on the web.

Training and Development

Training is a critical component of open source engineering because you’ll need to train developers, legal, software procurement, quality assurance, systems administrators, and others on the obligations of open source compliance. Additionally, you might need training for developers that have little to no experience working with an open source community on how open source development works.

Maintenance and Support

Proprietary software typically includes some level of paid support from the vendor company, which may include an SLA, pre-disclosure of vulnerabilities, or implementation support.  This is generally contractually enforceable, and it’s reasonable to demand responsiveness from the vendor in line with your support contract.  Similar support for OSS projects may be offered by companies participating in the ecosystem, but it is rare to find unpaid guaranteed support from the development community itself.  As most of the participants are either working on their own time or on behalf of an employer, it is neither reasonable nor fair to expect the same level of service as provided by a paid vendor.  As such, it may be the case where businesses that incorporate unpaid OSS into their products are responsible for installing updates and implementing security fixes and new modules themselves.  These tasks are easy to push aside in favor of more pressing issues, but they must be addressed nonetheless because a lack of maintenance can rapidly overcome the benefits of incorporating externally developed code.

To reiterate, OSS does not include any sort of support contract unless it is specifically negotiated with a third-party company that offers these services.  The most common OSS licenses specifically include a disclaimer of warranty.  If a business requires 24/7 support for services that use OSS, this will either need to be negotiated with an appropriate third-party company or the team will need to be hired in-house. Support services are a critical, but often overlooked, investment when using OSS.

Application Dependence

OSS can be a great avenue to avoid proprietary software dependence, but that doesn’t mean it’s a simple process to migrate away from OSS that no longer meets the requirements of a company. Whenever OSS is used for business-critical applications, the business becomes dependent on the community and project.  Changes that go against the interests of the business could result in the company needing to migrate to an alternative. The effort required to make this switch can vary widely depending on the availability of expertise and the maturity of the projects being migrated between. OSS community support can mitigate this problem, but this also varies substantially from project to project.  In general, it is considered a best practice to be actively engaged with and support select OSS communities to reduce the risk of unexpected changes to critical components.

Strategic Dependence

Open source leadership can bring substantial benefits to companies that properly leverage it, but the independent nature of open source communities can complicate strategic decisions. For starters, open source community choices may preclude downstream requirements, particularly if a company does a poor job of communicating with the upstream community.  This can introduce added effort to maintain downstream products. Additionally, if the community doesn’t have a formal technical roadmap, planning can become much more complicated. Finally, all software whether open or proprietary fits onto a spectrum of maturity, and this can often reflect the needs of a community.  For example, software developed for home use or for academic research may require some level of investment to meet product security requirements.

Do the Benefits of Open Source Outweigh the Obligations?

This article should have provided you with a general understanding of what obligations and risks are associated with the use of OSS in a product or service. There is no one-size-fits-all solution for whether a company should use OSS or simply buy software from a proprietary vendor, so it’s always important for any business that’s considering the use of OSS to consider their own specific requirements.  However, the overwhelming trend in the industry has been in favor of OSS components wherever possible, particularly in consumer electronics.

Here are some questions all businesses should ask themselves when considering the use of OSS in products.

  • How do the platform costs of OSS compare to similar offerings?
  • What commercial support offerings are available?
  • What license obligations does the code have? Does our company have the resources to fill them?
  • Who are the key individuals and organizations in the open source community? How long have they been around?
  • Do the open source community goals and roadmap meet our risk profile?
  • Does our company have adequate resources to support the use of OSS in our products?


Now Hiring: Open Source Cloud Engineers

The cloud is ripe with open source software as the collaborative development model has proven to be extremely effective at commoditizing much of the software stack. Today, foundations like the Cloud Native Computing Foundation are bringing together numerous companies to collaborate on vital, cutting edge technology, and open source software is doing what it has done in many other industries as it positions itself to be critical to the adoption of cloud technologies. More companies are launching open source initiatives to improve this technology domain and the Open Source Group recognizes this as a valuable place for us to increase our breadth of impact on Samsung’s innovation.

We’re Hiring Cloud Experts!

With this said, we’re pleased to announce we’re hiring multiple positions for experts in open source cloud technologies to help us in our mission to improve Samsung’s understanding and adoption of open source software. Here are the most important skills we’re looking for:

  • Programming experience in one or more languages, including C++, Go, Python, Shell, C#, Ruby, JavaScript, and PHP. Please note that the language competency depends on the project you’re expected to get involved in.
  • Expertise contributing to one or more of these projects: Kubernetes, OpenTracing, Jaeger, Envoy, Linkerd, gRPC, Fluentd, and related CNCF projects.
  • Knowledge of distributed tracing, monitoring, service management, and container orchestration.
  • Demonstrable experience participating in open source communities as a contributor, committer, or maintainer.
  • A history of providing technical leadership within open source communities and engaging in political influence and guidance.
  • A high degree of self-motivation and the ability to work alone, managing your own work and setting sensible priorities.
  • Background in pipeline operations, packaging and deployment of cloud applications, virtualization technologies and API’s,

However, don’t worry if you aren’t experienced with all of these skills; the most important skill you can have is the ability to expand your own technical knowledge to meet the rapidly changing open source software ecosystem. If you have knowledge of any of these items with a history of good open source contributions, we want you!

Why Work for Us?

You’ll want to work for us if you’re interested in:

  • Spending 100% of your development time on upstream open source projects,
  • Working from almost anywhere in the world (as long as you have an internet connection),
  • Using your preferred infrastructure for your development environment,
  • The freedom to work outside the pressure of product deadlines, and
  • Improving your visibility with open source communities via participation in project governance and events.

If you’re someone who’s passionate about open source software and deeply knowledgeable about the things mentioned in this post, we’d love to hear from you. If you’re interested, send us a message on twitter @SamsungOSG or an email to hiring[at] If you want to learn more about our team, check out this blog post that explains why our team was created.

We look forward to meeting some great open source engineers!

The Business Value of Open Source Software

This article is a part of a series on using open source in business:


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.

Simplifies Licensing

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

The Business Value of Open Source Software - OSS-Business-Value

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.

Join Us for the Tizen Developer Conference in San Francisco

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, Z2Gear 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.

Check out the entire conference schedule here.

What are You Waiting For?

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.

We hope to see you there!

What Does the Samsung OSG Do?

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!

The Technical Value of Open Source Software

This article is a part of a series on using open source in business:

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.

The Technical Value of Open Source Software - OSB3-tools-v2-1.png

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.

Check Out the Free Open Source Compliance Handbook

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!

An Introduction to Managing Enlightenment Widget Focus

In Enlightenment, a widget can have focus, meaning that once a key on a keyboard is pressed the events will be delivered to the focused widget, and the widget can then react to the event. For example, a text field will start to append the letter ‘a’ once the appropriate key is hit on the keyboard; once the key is released, it will stop appending the characters. In other words, the focused widget is the widget that gets attention from input events.

There can be several reasons for a widget to get focus, such as when a user clicks on it. But, there are also use cases where the user doesn’t have a touchscreen or mouse, such as on a TV, and needs to rely on a remote to control the focus on the screen. There are six directions that provide an optimal method for moving the focus around in an app. Four of them are based on position: up, down, right, and left.

The other two are based on the workflow of the particular app. For example, a login screen has two text fields: one for the user name and one for the password, and two buttons: one for canceling the login, and the other to submit the login information. It’s possible to use one of the positional methods I just mentioned, but it would be much easier to have a direction that guides the user from the user name field, to the password field, and finally to the submit button since this is the usual workflow a user would follow on this particular graphical interface.

So after we know what’s needed to provide a user with useful focus operations, we can start to think about how to realize it. My personal opinion is that there should be an object that registers all of the widgets that should be connected to each other. The first four directions can be calculated based on their position in the app, but the workflow directions are not that easy because there isn’t a general way to get these directions. This means the workflow directions should be left to the app with some fall-back logic that makes it so the app isn’t forced to setup the next widget in it’s workflow. For example, it would be possible to set a container in which the next direction always triggered the widget that sends the user to the next page.

To calculate the right, left, top and down candidates for a single widget, the distance from the currently calculated widget to all others in the set needs to be compared. It’s possible to find the smallest distance and store the associated widget, however, there is one problem with this. If the user interface is rather large with many widgets, it can get quite expensive to calculate the distance to all other widgets. So, the idea of positional focus isn’t easy and requires a bigger amount of work than what might be apparent initially. This problem with finding the shortest distance is not just a problem in EFL, it’s also a problem in theoretical computer science. It’s known as the shortest path problem, and is most commonly encountered when creating car navigation systems.

Overcoming Technical Roadblocks

As I wrote in my previous blog post, a major source of problems is non-revertable actions. Once a user moves the focus to the right, there is no assertion that moving the focus to the left will bring the user back to the widget where the focus previously was. There is some history to solve this, once a widget is the focus it will move to the top of a history stack, much like a web browser history. With this, it’s possible to take the set of shortest distances to the left side from a widget and find the one that has the most recent position in the history, allowing the user’s action to be reverted.

The second problem with the old solution was that a few widgets might be inaccessible in a huge user interface, meaning they can’t receive focus by using one of the directions. With this new solution, every widget is put into a set of widgets, and if s set contains at least two elements there is at least one minimum distance between those two. This means the widgets are guaranteed to be accessible with the positional-based directions.

I hope this post gave an adequate overview of a alternative solution that could solve these problems in EFL. In my next blog post, I’ll describe the debugging process for focus problems in EFL user interfaces.

Satisfying Enlightenment’s Launcher Appetite with Luncher

Ibar has been Enlightenment’s primary launcher for at least a decade. What it lacked in features it gained in simplicity. However, as Enlightenment has grown, ibar has seemingly stayed stagnant. I wasn’t surprised when Mike Blumenkrantz informed me this would be one of the focuses of my internship. From the depths of Enlightenment’s growling, starving stomach, Luncher was born.

Satisfying Enlightenments Launcher Appetite with Luncher - luncher
The Outdated ibar Widget

In my previous post, I gave an introduction to developing gadgets for Enlightenment using the new gadget API; I did so by converting an existing module to the API, and this preparation was one of the first steps in creating Luncher. Mike and I spent weeks on end discussing ideas for Luncher including both necessary and wishlist features. We kicked around ideas and shared visuals of what we would like Luncher to be, and we identified weakness in ibar that must be improved for Luncher. In the end, we determined a simple launcher bar with elegant window previews and more aware code for complete taskbar management would be the focus of Luncher. Add in a catchy interface and smooth effects for iconifying applications, and the recipe was complete. All of this was happening while I was learning the new gadget API with pager, which was a measured approach to hit the ground running with Luncher, and hit the the ground running I did.

Being well prepared with the gadget API, I got the basics of luncher created in no time: create a gadget site, create a box to hold icons, and display icons. The next step was executing applications when icons were clicked, and this too was very easy. You can see in the following video how the gadget was coming together early on.

Everything past this point became more challenging. The most difficult task was writing the window previews popup. This involves keeping a list of open windows and matching them with their icon in the Luncher. As you can see, it always takes trial and error, and I was certainly not having fun.

Satisfying Enlightenments Launcher Appetite with Luncher - previewHowever, persistence is key when developing software, especially when visual appeal is important. After much trial and error, I managed to get the window previews into a state that Mike and I both liked (A Hallelujiah! might have been heard from my office).

Satisfying Enlightenments Launcher Appetite with Luncher - preview_final
The Finished Launcher Gadget

Once the previews were finished, the rest of development focused on stability and usability. Mike and I used the gadget extensively to make tweaks where we thought it would improve the user experience. When working on this stage, little things happen that might never seem apparent to the user. We move an image one pixel to the left or to the right, shift a box to align a different way, determine the best size for certain objects, etc. While this stage of the development may seem easy, it’s one of the most time consuming and involves constant rebuilding and testing only to rebuild and test again, over and over until things are just right. It involves a lot of tiny changes such as a single number or word, so the rebuild takes longer than the changes take to make. Then, the testing takes all of 5 seconds before the next tiny change is found. This is the cycle of the final stage of development, I recommend a lot of coffee.

Completing a project like this is always rewarding and is also the gift that keeps on giving as you get to use it in your own work. Luncher is now available in Enlightenment git repo. Stay tuned for further developments as I work on a grid version of Luncher as well as system info gadgets!

Samsung OSG Intern Profile: Michaël Bouchaud

My name is Michaël Bouchaud, and over the years I’ve been a software developer with several companies; I’ve now become the most recent intern in the Samsung Open Source Group internship program. In this post, I’ll share my new activities, but first, I’ll introduce myself.

How I Got My Start

I’ve used Enlightenment since E16 was my desktop window manager while I was in high school. What attracted me to this environment the most is the fact that it’s lightweight and sits on the side of the interface, allowing it to be effective on both mobile and desktop. I was always a rather good math student, and I studied computer science, mathematics, physics and chemistry at university. At the end of my studies, I looked for work primarily in a Linux environment; the search was not easy, but I came across Substantiel, a little French company that works with Debian. It was exactly what I was looking for: creating graphical applications in a UNIX environment. This company develops Ordissimo, an operating system targeted at beginner computer users. When I arrived, a first version of this operating system already existed but it was aging; during my time with the company we undertook a major job to rewrite the entire operating system. My task was to make a window manager that was adapted to our needs; for this, I used Enlightenment. The applications also needed to be rewritten, resulting in us using EFL since I was already active in the community.

I enabled my developer team to utilize EFL while also acting as a point of communication to the open source community. Nearly all of the applications were made using Elementary, but one of the biggest problems we encountered was that Elementary was very young at the time so we ran into a lot of bugs as well as a general lack of widgets. With that said, it enabled us to strip the graphical interface of the product down to simplify its use, while remaining very close to a standard PC environment. While this didn’t provide access to all of the capabilities of Linux, it did provide easy access for our customers.

Here’s a quick video that demonstrates the resulting interface.

After leaving Substantiel I went to work for Thales where I introduced EFL to several of the company’s projects. I’ve also spent a considerable amount of my free time contributing to EFL; my first contribution was the progress bar widget in Elementary. Since then, I have written entrance: a login manager and libekbd: a virtual keyboard library. I hope to eventually integrate libekbd into EFL and use it in the weekeyboard module that’s present in Enlightenment today.

What I’ll be Contributing on Behalf of Samsung

Now, my role in Samsung is to write an API for managing application volume in Enlightenment; this is possible through PulseAudio. I will take advantage of this API to create controls in a handful of places in Enlightenment so users can enjoy it. We’ve also noticed that the keyboard layout setting for Enlightenment is painful and unintuitive. I will propose an alternative solution to simplify its interface and provide a more natural configuration.

Mike Blumenkrantz introduced the new Enlightenment Gadget API in E 21, as well as a new gadget container named Bryce. I will make a Bryce migration wizard that makes it easier for users to move from the old configuration. Finally, I will also make two new gadgets: A post-it to quickly create notes on the desktop, and a weather gadget.

I really enjoy the opportunity given to me to work with other open source enthusiasts, and I can’t wait to bring my experience and motivation to this project!