Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source

Samsung Open-Source Group Reportedly Shuts Down (phoronix.com) 50

At a time when several companies have grown new interest in open sourcing part of their offerings, Samsung appears to be going the other way. The company has shut down the Samsung Open-Source Group (Samsung OSG), according to a report. Phoronix, which reported the development, offers some background: Samsung's Open-Source Group had been structured within Samsung Research America. Samsung OSG was formed back in 2012 and has employed dozens of developers over the past number of years. Samsung OSG was akin to Intel OTC (Open-Source Technology Center) albeit with not nearly as many developers nor as many original open-source projects brought up by the Intel software crew. The Samsung OSG stated purpose has been to "enhance key open source projects through upstream contributions and active involvement with open source foundations." Samsung OSG has contributed very heavily to the development of Wayland as well as some X.Org components, Cairo, Enlightenment EFL, the LLVM Clang compiler, GStreamer, FFmpeg, the Linux kernel, and other related code-bases that helped benefit Samsung's open-source/Linux needs across their wide portfolio of products from smart watches to refrigerators.
This discussion has been archived. No new comments can be posted.

Samsung Open-Source Group Reportedly Shuts Down

Comments Filter:
  • Just write checks? (Score:4, Interesting)

    by bigpat ( 158134 ) on Tuesday October 30, 2018 @11:21AM (#57562315)

    Managing an open source project appears to be difficult enough. Try having two masters one in the open source project community and one in the company that writes your pay checks. I think maybe open source is best when companies just contribute money to the projects and let the projects themselves figure out how to distribute money to whomever is providing the most value.

    The exception I could see would be when a company itself controls the open source project and is merely contributing the source code back to the community because of the terms of the license.

    Somewhere in the middle, it seems that letting your employees contribute to open source as a small fraction of their time would seem to work. Kinda in the same way that in some industries, publishing to technical, scientific or business journals is normal and important.

    Overall, just need to make sure the value flows make sense and are sustainable for the company, the employees and the open source projects.

    • Just paying them money, doesn't guarantee their needs are met.
      I want x.org to support this touchscreen that I could purchase in bulk for $5.00 less then the competition per unit. The general project people, may not have objection to supporting such device, but just doesn't consider it a high enough priority. So you have your developers put in the patch and have them implement it. If they refuse it you can still have it as a fork in the product which is probably still good enough to release the product us

    • by raymorris ( 2726007 ) on Tuesday October 30, 2018 @11:41AM (#57562497) Journal

      For fifteen years I was involved in contributing to the open source software my company used. For three years after that my job was pretty much nothing but contributing to open source, and some level 3 support for the open source software.

      Here's how it workes for me. My organization wanted feature A to work better, and they wanted to add feature B. They needed bug X fixed in the open source software. I fixed the bugs that bugged them, and added or improved the features my employer wanted. It worked very well for my employer and I for the project.

      One example was a RAID bug in the Linux kernel. A specific configuration stacking LVM with snapshots on top of RAID in a certain way would sometimes lock up. That was the configuration my company used, so I fixed the bug. Most of the other contributors were similar - it's basically a thousand companies, schools, and other organizations cooperatively developing and maintaining the software they all use.

      My organization COULD have kept my work private, but that would be costly for them because they'd be having to re-do the work now, a few years after I left. By integrating it upstream, it continues to work, and even be improved, by others in the project.

      You mentioned communicating the value. That was my main communication - less than half the cost of software is the initial development. Maintenance, including keeping documentation and tests up to date, is over half the cost. Why would we double our costs by maintaining our own version of the kernel, or our own LMS, when the project members would rather maintain those features and fixes FOR us, and all we have to do is submit a pull request? The project even provided multiple levels of peer review, language translation, and documentation written for free. It's much cheaper and more effective for us to cooperate.

      • This is why I've never understood some of the arguments by some people against permissive open source licenses, such as "it could be forked and kept closed" by some corporation. If an organization uses a piece of open source software, it's actually in their own interest to push fixes and improvements back to the mainline, because otherwise, maintenance becomes a pain, as they've now taken on responsibility for maintaining an entire fork on their own.

        • It's generally in their best interest to cooperate, true. It significantly reduces their costs.

          Perhaps not knowing this, companies DO in fact regularly do exactly what the GPL seeks to prevent - even violating the license in so doing.

          It is helpful to set up the overall system such that a self-interested rational actor does things that are good for the society. That's because frequently people do the rational thing. For example, if an economic system rewards with peofit those who make cool stuff for the re

        • It doesn't stop a pointy haired boss from mandating a fork, and then realizing 3 years later your point. Even worse, that pointy haired boss could be off messing up another division of the company by that point. Why do people do stupid things?

    • SGI (Score:5, Informative)

      by jd ( 1658 ) <imipakNO@SPAMyahoo.com> on Tuesday October 30, 2018 @12:07PM (#57562743) Homepage Journal

      When SGI got involved in open source, they contributed:

      1. OpenGL Performer(High-Performance 3D Rendering Toolkit)
      2. SGI Pro64TM Development Tools
      3. Linux Digital Media Projects
      4. dmSDK (Digital Media Software Development Kit)
      5. Audio File Library
      6. Linux Scalability patches
      7. CpuMemSets (Processor and Memory Placement)
      8. Kernprof (Kernel Profiling)
      9. SGI kGDB (Remote host Linux kernel debugger via GDB)
      10. NUMA (NUMA support in Linux)
      11. Bigmem (Big Memory support for Linux)
      12. Lockmeter (Linux kernel lock-metering)
      13. Post/Wait (Post/Wait Synchronization)
      14. SGI kdb (Linux kernel debugger)
      15. Raw I/O (Enhancements to Linux raw I/O capabilities)
      16. POSIX Asynchronous I/O (KAIO)
      17. LKCD (Linux Kernel Crash Dumps)
      18. STP (Scheduled Transfer Protocol)
      19. CSA (Comprehensive System Accounting)
      20. PAGG (Process Aggregates)
      21. GLX (OpenGL extensions to X)
      22. OpenGL® Sample Implementation (Standard Cross-platform 3D and 2D Graphics API)
      23. Open InventorTM(object-oriented toolkit for interactive 3D graphics)
      24. Linux/MIPS (Indy etc.)
      25. Linuxï½ FailSafe (SGI FailSafe for Linux)
      26. NFSv3 (NFS Version 3 work for Linux)
      27. XFS (high perf journalling file system)
      28. fam & imon (File Alteration Monitor and Inode Monitor)
      29. OpenVault (mass storage management and framework)
      30. CSA (Comprehensive System Accounting)
      31. PAGG (Process Aggregates)
      32. Linux ACE (Advanced Cluster Environment)
      33. Accelerating Apache Project
      34. Jessie (Cross-platform IDE)
      35. STL (C++ standard template library)
      36. Open SpeedShop for Linux (Performance Analysis Tool)
      37. PCP (System Performance Monitoring and Management Framework)
      38. LTP (Linux Test Project)
      39. State Threads Library
      40. Rhino(Infrastructure for System Administration Applications)
      41. i18n(Linux Internationalization)

      And other open source work included:
      Samba for IRIX (Windows® / Unix® Interoperability)
      ob1 (Sample Implementation of a Trusted Operating System)

      Now, let's look at these projects. There's a lot there. Some wholly internal, some collaborative. Some succeeded, some failed dismally.

      I can see no obvious relationship between who controlled it and success, scale of project and success, or any other parameters and success. It seems to have been fairly random.

      If anyone wants to go through and note which ones were abandoned, which ones absorbed and which ones succeeded, that would be great. Pointless, as I'm probably the only one interested, but great.

      • by MrMr ( 219533 )
        I recognize a few that still have some relevance in HPC. In fact without the SGI effort spent on NUMA, bigmem and scalabilty support for Linux the current top-500-by-OS list would look completely different.
        https://www.top500.org/statistics/list/
  • by jellomizer ( 103300 ) on Tuesday October 30, 2018 @11:22AM (#57562333)

    The problem is most of the Open Source Teams are mostly all technical folks. Who really suck at explaining their value to their company, especially as they are sharing their hard work for free to their competitors. So they are considered a cost center vs a profit center.

    What they need are some sales people to really boost their value to higher management.
    Explaining how they are leading the industry and forcing other to just follow, and by being strong in the Open Source community you push your standards downward, vs hoping for the best and having to reword some of your ideas because someone else had won the standard war.

  • This is my bad guys. It made the mistake of suggesting we standardize on using either Vi or Emacs and management thought it was a great idea. By the end of the day, the mail server was crawling and someone lost their shit and destroyed all the servers when management chose Vi because "Emacs has everything but a good text editor". #CautionaryTale

  • I'll have to install debian or netbsd on my refrigerator now.

    As long as I can run doom on it... /s

  • IBM - I can't find their development group, think it shut down.
    SGI - Whole business shut down
    HP - Their development group is AWOL. Since they own SGI, SGI's OSS is AWOL too
    BBC - http://www.bbc.co.uk/opensourc... [bbc.co.uk] - Still there but Dirac is missing

    NASA isn't a business and their open source is horrible.

    So really, although open source has a lot of followers in companies, that doesn't extend to management.

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...