Oss In A Corporate Environment


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Marketing Benefits Creates a better image of the company social awarnessincurages interaction with other companies Allows the company to concentrate on it critical buisness domain Risks Customers must be informed about the use of OSS and impacts this might have on delivery of issues explain to the customer that sharing the source does not hinder the sucurity of software this is achieved today via enrypted keys, firewalls Technical Benefits Tested by many people Allows the reuase of knowladgeaquired elsewhere - university other companiecode reviewed through many eyeballs Risks code quality maybe] unknown this is very important for OSS that do not have a large community Timing of future release with new bug fixes Delay between fix/functionality implemention and community acceptance Financial Benefits Lower cost of maintenance? initial costs are minimal No licencing costs end of life cycle donating software to the community may be a cost effective way to handle maintenance on old software this also gives the customers ability to modify the software to their needs this might be efficient if the company has dicided to concentrate  on a different buisness domain Risks Support contracts? it is common for other parties to specialize in this area examples RedhatSuseUbuntuMandrake Symas ~ copyleftThis might also prevent companies from charging for their products Benefits and disbenifits must be shared together with the customer Legal risks viral effect of copy left(GPL) when code is linked or incorporated into a companies domain logic that software might also have to be release it this might go the other way when the company wants to release a product as opernsource by not allow others to utilize it inside of it's products dual licencingsomtimes this gives the possibility to buy enhanced rights from the owner of the software adherence to certain licences may be complicated as they do not have to be clearly drafted possible licencing issues can be provided without any intelectual property idemnification or warranty company may be held legally responsible for any patent or copyright violations example HTC, Samsung These cannot be forwarded to the original contributors must be drafted into the companies outbound licencing terms and made apparent to the customers contractual support of OSS does not have to cover IPR redhat provides some limited guarenteesCompatibility of licenceslicences that contradict each other are incompatible and software cannot be combined Most opensourcelicences are general templates these might be changed for a specific source code never assume two Apache 2.0 licences are the same
  • Basic platform built on top of RedHat that adheres to the ELO Support guaranteed localized inside of a separate project Distribution Layer incorporates open source packages not present in the basic platform present but with a different version communicates towards the open source community Internal software must adhere to rulesMinimal documentationBenefitsCost Aggregate LicensingAligning ArchitectureLimits Duplication of EffortCommunication with the OSS CommunityFaster UpdatesThird Party Support ContactComponentsLocalization of larger OS projects into separate entities BenefitsCost Aggregate LicensingAligning ArchitectureLimits Duplication of EffortCommunication with the OSS CommunityFaster UpdatesThird Party Support Contact
  • Oss In A Corporate Environment

    1. 1. Open Source Software in a Corporate Environment <br />September 2011<br />Slide Number:1<br />
    2. 2. Overview<br />Four aspects<br />Creating structure<br />Extra: Case Study Symas <br />
    3. 3. four aspects of OSS integration<br />Slide Number:3<br />
    4. 4. The Four aspects<br />Slide Number:4<br />Financial<br />Technical<br />Legal<br />Marketing<br />
    5. 5. Financial<br />Technical<br />Benefits<br />Initial costs<br />Licensing<br />Maintenance?<br />End of life<br />Concentration <br /> on Business <br /> Domain<br />Risks<br />Support contracts<br />Copyright/left<br />Risk to customers<br />Benefits<br />Mostly ready<br />Standards<br />Knowhow<br />“Many eyeballs”<br />Tested<br />Fast Turnover<br />Risks<br />Quality?<br />Release Timing<br />CR, bug <br /> acceptance<br />Too general<br />Legal<br />Marketing<br />Risks<br />Viral Effect<br />Licenses may be<br /> unclear <br />Intellectual Property<br />License <br /> incompatibility <br />Risks<br />Manage<br /> Customer<br />Benefits<br />Company Image<br />Interaction with other parties<br />Concentration on Business domain<br />Slide Number:5<br />
    6. 6. Creating structure<br />Slide Number:6<br />
    7. 7. Slide Number:7<br />
    8. 8. OSS Decision Maker<br />Authority to reject/accept<br />Gets legal guidance<br />Notifies Product management/Sales<br />Slide Number:8<br />
    9. 9. Isolating the OSS in Layers<br />Business <br />Domain<br />Product 1<br />Product 2<br />Product 3<br />Component 1<br />Component 2<br />OSS<br />Distribution Layer<br />Third Party<br />Core Platform<br />Platform<br />HW/CLOUD<br />Slide Number:9<br />
    10. 10. Distribution Layer Risks<br />Risks<br />Mitigation<br />Updating Between Product Releases<br />Backwards Compatibility<br />Slide Number:10<br /><ul><li>Community Development
    11. 11. Resource Management
    12. 12. Central Design Authority
    13. 13. Fragmented Architecture
    14. 14. Product Wide Heart Beat
    15. 15. Aligning releases
    16. 16. Contract OS Support
    17. 17. Providing Support</li></li></ul><li>Slide Number:11<br />Financial<br />Technical<br />Risks<br />Quality?<br />Release Timing<br />CR, bug acceptance<br />Too general<br />Risks<br />Support contracts<br />Copyright/left<br />Risk to customers<br />Legal<br />Marketing<br />Risks<br />Viral Effect<br />Licenses may be unclear <br />Intellectual Property<br />License incompatibility <br />Risks<br />Manage Customer<br />
    18. 18. collaboration<br />Slide Number:12<br />
    19. 19. Third part Case Study: Symas<br />Slide Number:13<br />Corporate LDAP requirements<br />Replication stability <br />Write performance<br />High availability<br />On a single site and across sites<br />Read performance scaling<br />No manual actions during site failover<br />Full and Fast Replication stability is the only requirement that the current OpenLDAP solution is not able to provide<br />
    20. 20. Slide Number:14<br />Third Party<br />
    21. 21. Summary<br />Four aspects<br />Creating structure<br />Case Study: Symas<br />
    22. 22. Q/A<br />Slide Number:16<br />How much?<br />What?<br />How many?<br />Where?<br />Why?<br />Whose?<br />Who?<br />Thank You for Your<br />Attention!<br />Whom?<br />When?<br />Which?<br />