Recommended
More Related Content
Similar to Sourcing Open Source
Similar to Sourcing Open Source (20)
Recently uploaded
Recently uploaded (20)
Sourcing Open Source
- 1. Sourcing Open Source Updating Procurement for Competitive Advantage Charlotte Lawson, CTPE, CCCM, MLIS
- 2. Not on the Agenda History of Open Source Proprietary vs. Open Source Legal review of OS terms Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 2
- 3. Procurement Professional Agenda Open Source – fad or forever? Competitive advantages Procurement’s part to play OSS Policy recommendation Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 3
- 4. Fad or Forever? Lines blurred, pervasive Faster/deeper time to market Increased competition Service is the differentiator Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 4
- 5. Competitive Advantages Finance: no sunk license costs Developer: community support/feedback Human Resources: education & engagement C-Level: rapid innovation & time to market Legal: from policing to partnership Individual: their needs drive development Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 5
- 6. Competitive Advantages IT: best value service & support • Switch service without switching software • Forego or in-source service • No forced upgrades or planned obsolescence • No corporate spyware Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 6
- 7. Needs Definition #1 Intended Usage Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 7
- 8. Needs Definition #2 Impact to Operations #3 Security (Data security) • Installed behind firewall • Hosted Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 8
- 9. Sourcing All the usual sources OSS dedicated organizations OSS divisions of commercial companies OSS industry work groups Developer Coding Groups (in every community) University research groups Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 9
- 10. Analyze Options Always Demo OSS • Stand up a server or sandbox • “Free”, Trial, Community Ed. • Update frequency • Longevity in the market Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 10
- 11. Analyze Options Support is Key Online community strength On-call expert listing Paid Enterprise Support • SLA • Response time & Recourse • License count Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 11
- 12. Vendor/Community Qualification Check Industry Boards Call references Size of the community On-line presence Availability of commercial support Project maturity Funding source Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 12
- 13. Contracting Internal Use OSS CSS Cost Term Users Updates Support "Free" Download $0 Unlimited Unlimited none online Timed Trial $0 Limited Limited none online Community Edition $0 Unlimited Unlimited standard online Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 13
- 14. Contracting Distributed Use *User limit is due to support, not license grant. ** Some Software Publishers will grant commercialization for a nominal fee. OSS CSS Cost Term Users Updates Support Developer Edition $0 to $ Unlimited Limited standard varies Enterprise Edition** Enterprise Edition $$$ perpetual/ subscription Unlimited* standard full Distribution/ Provider License (e.g. ASP, ASL, SPLA) $$$$ (revenue -based) subscription Limited standard full Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 14
- 15. Comparison Review Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 15
- 16. OSS Stakeholders Linux Foundation's Self-Assessment Checklist Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 16
- 17. Policy Recommendation For any software or code (whether licensed, open source, trial, freeware, Company IP, etc.) to be tested for use in Company’s products, the coding source and version must be documented in [[code track]] system for regular reporting to and review by IT, Legal and Compliance management. No software code may be distributed for use in Company’s products or installed for internal use until appropriate license grant and support terms are confirmed on file in the Legal department. Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 17
- 18. Resources Public Communities: http://opensource.org/licenses - Open Source Institute (OSI) https://www.fsf.org/ Free Software Foundation http://www.linuxfoundation.org http://gpl-violations.org/faq/vendor-faq.html Commercial Blogs: http://www.opensourcedelivers.com/ (BlackDuck) http://www.openlogic.com/blog/ Industry Specific: http://www.oss-institute.org (Government) http://www.mil-oss.org/ (Military) http://code.ohloh.net/ OSS code search Charlotte E. Lawson, CTPE, CCCM, MLIS clawsonPRG@gmail.com Sourcing Open Source 18
Editor's Notes
- As we are all well aware, IT procurement is ever changing. What we purchase for our companies today will be out of date next year. What we purchase for our companies next year may not even be on the market yet. Of all the purchasing specialties, IT Procurement Professionals must thrive on change and challenge to help the IT teams that we support keep up with the changes in IT. I have been in Contract Management and Purchasing roles since 1996. That was about the time when the Internet and e-mail, which had only begun to be used in businesses in 1990, became an essential requirement to stay in business. Now competitive businesses need a website, VPN remote access, virtualized networks, social media presence… I thrive in environments of change. So for over six years now I have worked exclusively in Procurement IT and acquired a Masters in Information Science from Florida State University in 2009. It’s a passion for me. Today we will be focusing solely on Open Source Software and how it impacts our Procurement roles to determine how we can best help our companies leverage the competitive advantages of OSS.
- First, this presentation will not cover. History of Open Source, except to provide a simple definition – Software whose license grant requires the source code be available to everyone without discrimination. It is all about the code being freely available to everyone. OSS is specifically licensed to ensure that the source code (and any changes) remains available to everyone, always. No one person, organization, or state can have a commercial monopoly on the code or its changes. Pros and Cons of proprietary software and open source software. Copyright and patent laws were put into place to incentivize the creation and distribution of works – a laudable goal. But with respect to software development who is the greater driver of creativity – OS communities or big corporations holding proprietary licenses? Well, the OS community has created OS licensing terms to allow this question to move from theory to practice. By the end of this course, we will understand the differences between the two models. Thereafter, I leave it for us to ponder and debate outside this course which is the better. Legal review of OS licensing terms. Of course, we should become familiar with these terms and fortunately OS terms are written in very plain English and have been fine tuned for two decades for their intent to be clear and understandable. We will cover the basics as they impact our procurement controls and processes. Then, at the end of this course to continue our understanding of Open Source there will be links to online resources for researching OS history, debating its merits, and all the OS licensing terms in popular use today.
- We will be discussing: Whether OS is a fad and should be avoided by procurement professionals, often at the behest of our legal counterparts. After all OS is only a couple of decades old. OR is OS likely to be around forever warranting procurement professionals to jump on the bandwagon to strategically source and perhaps even advocate its use. Competitive Advantages from the perspective of the different business teams we support and interact with. Procurement’s part with respect to OSS during the different phases of a software procurement from defining the need, sourcing research, analyzing options, qualifying vendors and contracting. We will drill into options for procuring IT access to appropriate support while the software is in use to manage our organization’s limited IT resources and mitigate business risks. Finally, I’ll put out there a Policy framework to start from that we can tweak and polish as we decide how best to support OS use in our organizations.
- By a show of hands -- How many of us use OSS in our companies? How many of us use OSS in our personal lives? Whether you raised your hand or not everyone, whether you realize it or not, uses OSS everyday. If you turned on your computer or use a smart phone or tablet, you are using OSS. Even the top Software Publishers have OSS embedded in their products. They cannot afford not to or the little guys will eat their lunch. OSS is pervasive. Using an OSS monitoring service like BlackDuck or Open Logic lets us see just how far and wide OSS code is being used in our organization’s proprietary software OR the extent of “free” software downloaded by staff that are $0 acquisitions bypassing procurement’s controls. http://opensource.com/ OSS allows faster and deeper market saturation. This is expected when entire development communities work on issues, not just the developers in-house. When programs are distributed free or at lower cost to a) the non-developer world (free word of mouth marketing, go-viral) and b) the developers who want freedom to modify and enhance the code for their own uses (free development services, more varied usage ideas). Recall, Apple and Blackberry were the leading mobile platforms in 2009. At that time Android opened its API and by 2010 it had surpassed Apple and Blackberry in number of users and now holds a 53% market share worldwide compared to Apple’s 36%. http://www.comscore.com/Insights/Blog/Android_vs_iOS_User_Differences_Every_Developer_Should_Know#imageview/0/ Increased competition is always music to a procurement professionals ears. It is the organization that executes and provides stellar support that wins in the OSS world, not the organization that has the best fleet of salesmen and copyright and patent lawyers. Which do we value more? Service is the differentiator and support services have always carried higher margins as value-added services. With OSS it no longer makes sense to pay hundreds of thousands for the right to use the code (with a 30-90 day warranty period and only the promise that the Software Publisher will keep the code competitive in the marketplace, free of security holes, and quality on-call support). They already have your money, sometimes years in advance of performance. Our companies will put up with a lot when they are heavily invested – but putting up with low quality or costly work arounds erodes our competitive advantage. OSS support is more easily provided by third parties as well as the original Software Publisher. OSS Software Publishers can more easily transition older or little used programs to third party providers, keeping their loyal client base happy while saving costs. Then the client base moves back to the original SP when the client is ready to upgrade to program versions the SP is supporting. A very cool, symbiotic relationship. With these drivers it is unlikely Open Source is a fad and the proprietary Software Publishers are either moving to OSS models OR rebranding and building ecosystems to bring these OSS competitive advantages to their proprietary worlds.
- Competitive advantages of OSS are in the eye of the beholder. Here are few: Finance perspective: 1) If we are indiscriminately sinking costs into closed source (perpetual or subscription) license code due to fear of OSS, we are not only spending money that may be better invested elsewhere in the business, but also investing in assets that are likely to be technologically out-of-date before a full return on investment is realized. 2) We call software code purchases “assets”, but the organization cannot resell these licenses or dispose of them by transfer. Unlike tangible assets, there is no residual value to recover once software is purchased. (Car resale value example) Developer perspective: 1) Developers gain access to an OSS community to learn and hone their skills and get broad-based feedback on their methods and innovations. They can round out their resumes, find mentors, or gain skills to take on more challenging and exciting projects in their companies. HR/Hiring Manager perspective: (e.g. Ruby on Rails) 1) OS communities are a vibrant source of real talent to tap into, whether for independent contractors, employees or consultants. 2) Encouraging employee involvement in OS communities keeps staff educated at the cutting edge and enhances employee engagement to retain the talent. C-Level perspective: 1) Every organization, from startup to Fortune 500, can leverage the knowledgebase of OS communities for faster time to market of their innovative iterations and fixes. Plus the knowledgebase is not lost should an individual developer choose to leave, slowing brain drain to the competition. The IT industry has one of the highest staff churn rates – a real problem for CS Software Publishers. 2) For Software Publishing companies specifically, OS allows cost-effective, highly efficient, and faster market penetration for the reasons mentioned before. Legal perspective: 1) Legal becomes the hero by developing tools and terms to allow their organization to leverage OSS to a) get long term value out of their IT purchases and b) consistently get their innovations to market first by developing the process to quickly and correctly package products containing OSS for distribution. Individual, end user, customer perspective: 1) Communication of their needs (boards, blog posts, surveys) drives OSS development. Post a feature request, endorse a feature in a prior post and almost magically the feature appears in the next few months. Product managers scour these boards for ideas that will improve their product sales and stickiness.
- Finally, the IT perspective: We all know software is warranted for 30-90 days upon download or delivery. It is the ongoing support that is of real value to the organization, not the license. With OS, Software support becomes competitive because IT can switch support providers without switching software. With the vibrant community dialog and developer portals, IT can choose to strategically break and in-source support for OSS. CS Software Publishers use forced obsolescence (sunsetting) to ensure future revenue. You are forced to upgrade or lose all support. Active OS communities break this cycle. No corporate spyware or other monitoring features for the benefit of the Software Publisher are embedded that slow performance or cause system conflicts. So is OS the answer to all software procurements? Not at all, but no organization can afford to ignore the competitive advantages of OSS and expect to compete in the marketplace in the future.
- So when should OSS be consider a viable option in a software procurement? This is where we come in. First step in a successful procurement – assess the need. The first most critical question… How do we intend to use the software? How many here work for companies who distribute software products or develop code for other companies? 90% of businesses are not software developers or distributors and only use software for internal purposes. If Internal use only, for sure throw one or more OSS options in the procurement for TCO comparison against CSS options. If Client Facing like a portal interface, “yes”, OSS stacks up well –many vibrant and engaging options on the market. Distributed or Conveyed as part of our organization’s products? If a organization is distributing software, unless they are designing code in a vacuum, from scratch they are already using copyrighted software in their product. Whether OSS or Closed Source (aka proprietary software) copyrights require we keep track of the code sources used in our products to: pay appropriate licensing fees to (or withstand audit by) proprietary Software Publishers, OR to offer the OSS code and its changes along with a copy of the applicable OS license at distribution An organization that is not tracking the code source (OS or CS) in their products is already out of compliance on both these fronts and needs to resolve this issue. (Procurement can help source that service for them )I Assuming the organization is tracking code sources, if you have not already done so, partner with legal staff and developers to draft a standard process for packaging to meet the OSS requirement. Remember S&H may be charged for delivery of OSS code on CD, access to an ftp library or any other reasonable delivery method. In general, software that will be distributed that includes OS code, requires that the code and any changes be made available to the end users. However, this does not apply to software that will be used internally or will be Client Facing (e.g. Portal) and not conveyed or distributed to others.
- Next the risk management question we ask of all software purchases. If this software is rendered inoperable, what would be the impact to operations? Can we easily revert to a manual process? Is there backup option? Can this software affect SLAs we offer in our services? How challenging would it be to transition data to a new software OR reestablish integrations between systems? Many of our companies have standard risk assessment questionnaires to meet various industry compliance requirements. Software transitions have become easier and easier with open APIs (Application Programming Interface) and database standards and should be part of any software specification today. But this question is intended to give insights into the level of support that will be needed and SLA specifics (latency, response times, credits) to be part of the procurement requirements. If there is little to no impact to operations, then OSS even free offerings can be considered. If there is an impact, depending on the risk tolerance of our organization, only OSS options with vibrant support communities should be considered. Finally, at a high level how will security be managed? Will the software be installed behind our firewalls with security monitored by us OR will it be a hosted solution? Our concern here is the security of our data, not the security of the code. OSS code tends to be more hardened than CSS code because it relies on open review and improvement of the code rather than a contract term that requires we won’t look behind the curtain at the code. The hackers will look. If installed, our InfoSec team will have a series of software due diligence questions about patching and security admin controls. In general, we have more maneuvering room as our data being managed by the software will also be behind our firewall controls. OSS and CSS are on an even footing here. If hosted, the hosting provider and hosting colo center both need to be certified secure (SSAE16 SOC I Type II is current standard) OR our InfoSec teams need to perform their own thorough security assessment (in their free time – unlikely). Likely any hosted OSS not in a certified secure center cannot be a contender. This is not usually a challenge with respect to the hosting colo, most are certified to be competitive. However, depending on the maturity of the OSS focus area, it can be a challenge to find certified providers. A certified colo does not mean a certified provider. The colo may have security controls, but if the provider does not have security controls in place too, then our data is not secure. It is essentially a supply chain review exercise in who can touch our data. Some exceptions. Some OSS are actual data downloads that just need to be filtered through our virus checks. E.g. IP locators, zip code lookups, industry coding sets, etc. The data flow is one way. Understand context of the data flow to assess risk.
- So we’ve decided that we should include an OSS option in a procurement. Where do we find it? All the normal sources for finding software apply. The copyrights may be different, but software is software. Technology Research Groups (Gartner, Forester) Tech review & matching sites (CNET, Capterra, PC Magazine) Industry Association websites or developer boards Software Publisher websites (e.g. RedHat) Venture Capital sites dedicated to software investment Etc…. The sources change as fast as the IT industry changes. For OSS there are also these options: OSS dedicated organizations: Apache Software Foundation, Linux Foundation, Free Software Foundation, etc. These contain lists of OSS software projects and downloads. OSS divisions of commercial companies: Nearly all mature companies have a community edition they offer free. It is the lead into their enterprise edition. A marketing ploy, but allows them to take competitive advantage of OSS free development. Some companies have divisions they have committed to being OSS to continually leverage the wide-spread review and improvement of their code. Industry working groups dedicated to crowdsourcing open source for the industry. http://www.mil-oss.org/ Type in your industry and “Open Source” in a browser to get started. Remember vetting is key as we will see on the next two slides. Ask your developers. They are attending Code camps and Code groups. They hang out on their industry boards and know which OS communities are robust and which are fledgling. Open source sourcing is wide and open, literally.
- So we’ve found some options and we need to vet them. Essentially OS and CS software analysis is the same. Always demo. There may not be any Proof of Concept support (and associated charges,) but OSS can always be downloaded for testing and analysis. If this is installed software, having a process to quickly stand up isolated servers for developers to freely try and test options whether “free”, on trial or an OS community version. It is unproductive for developers to know and see postings of code fixes that could help them improve their jobs or solve a problem and not allow them to touch it. Give them a route to do so that includes security review (if not procurement intervention due to $0 cost). If software will be hosted, the software provider can make a sandbox available to test. Many have links to sandboxes on their website accessible at any time. Also check out the number of updates in the last 12 months. While updates are free or low cost, if they are not frequent it is a sign of a lackluster community. Weigh this against Longevity in the market. If the Software has been in the market for many years and is highly stable, it may not see frequent updates.
- There are many support options with OSS. The right one depends on the outcome of the needs assessment for the specific software purchase. Online communities have blogs, wikis, download libraries, e-mail alerting, even ticketing systems and feature request posting. A robust community’s online support may be all that is needed. Hire an expert. Communities will list who is supporting their products other than the Software Publisher. It keeps their ecosystem strong. Have a call list available to purchase support assistance as needed for patching and updating. Paid Enterprise Support is frequently available from the Software Publisher or 3rd party providers. This is a revenue stream that supports the OSS community and adds value to our organization. Paid Support terms are the same for OS and CS. SLA metrics (uptime, latency) response time, recourse credits all in exchange for a fee. Check out the boards and responsiveness to the community before committing to paid support. The community will gripe if support expectations are not being met. When Support is paid, the license count can again become important as with CSS and is auditable. The cost to support 5 users is very different from supporting1000 users. 1 server vs 50 servers.
- Some metrics to qualify community strength
- Let’s look at a few licensing models. These are $0 options, but Procurement should ask to take a look at what is being planned for use on a regular basis. How many of us have seen Development get all the way through the QA process and then throw the product “over the wall” to Production who has to find budget for Enterprise licensing costs? It can get ugly, but it is also a place where we can show real value if we can engage early. Today’s community edition can easily turn into tomorrow’s sole source enterprise edition and all associated support costs. The biggest risk from a procurement perspective are technical staff falling in love with OSS or CSS no-cost options downloads. The technical staff don’t even realize they have started negotiations in their first conversations with the vendors, losing most purchasing leverage in the process. Like a stranger offering candy – these free offers really hook the technical staff. Vendors actually “spam” Developers with free, trial, and community editions to get investment in their solution. This greatly increases the vendors negotiation leverage before the words “budget”, “contract” or “procurement” are ever spoken.
- OSS is not always the lowest cost option when paid support is involved. Those responsible for budgets (Production Managers) and purchasing need to be brought to the table early. Possible Solution: Ask your Development team for a demo of your organization’s current code tracking system in use to see how and where code sources are tracked. Request regular code source reports to review with Development and Production teams for any coding that is likely to be pushed to production (i.e. before the Quality Assurance (QA or QAP) stage) to begin negotiation research on license grant and support terms that may be needed. Meet quarterly or bi-annually or at a certain stage in the product development work flow. Some Original Software Publishers will grant commercialization for a nominal fee to remove the OSS obligation, but do not expect robust software terms in exchange. Read the license grant carefully as this rarely applies to Distribution/Provider licenses.
- Let’s do a high level review of OSS vs CSS. Essentially they are the same. Software is software, provided it meets the technical need? Both are copyrighted and we must follow the rules set by the Software Publisher. What do you do if you violate the OSS copyright? The same thing you do when you violate the CSS copyright. Fix it. With CSS, you true-up licenses and settle with the CSS copyright owner. With OSS, you make the code available and settle with the OSS community.
- Whether it makes sense to include OSS in Software procurements depends on the culture and risk management of our companies. Here is a list of stakeholders and their roles to assess and survey whether and how OSS should be used in our companies. Does this look like the same stakeholders that currently manage software purchase, software asset management, and software product distribution in your organization? It should. Product Managers: train their teams to include OSS compliance early in the product development process to ensure timely releases Developers: disclose OSS usage early in development (idea stage before lobbing code set to QA). They are also frequently members of the OS communities. Contractors: Train employees and independent contractors under “works for hire” contracts on OSS culture and code management process. Architecture: identify OSS interface and interaction with CSS to help define discrete OSS code “package” to disclose upon distribution. Legal: The licensing expert. They need to be in close contact with the Architects and Product Managers. Examine the license terms of each OSS and CSS code set in the product. Sometimes there are conflicts and they need to be identified early to avoid holding up a release. Craft the flowdow copyright language (OSS and CSS) for the distribution. They will also make sure the organization’s OSS policy is incorporated in Works for Hire/Consulting Agreements and Developer Community Contributor agreements to clarify ownership rights. Perform OSS and CSS due diligence during an M&A event and engage staff to fix any licensing issues found. Product Documentation: They get the handoff from Legal on the copyright term to include in the distribution. They get a copy of the OSS code to be offered and manage the process for distributing the code should someone take them up on the offer to get a copy. OSS code can be provided at the same time as distribution OR only the OSS code offer is made at distribution, depending on how your organization is structured… Loop in a webmaster or data manager to manage the repository of OSS code with versioning control. Loop in Finance, of course, if there will be a charge for delivering the OSS code. Loop in Marketing to ensure products are appropriately described (full OS license text and offer routing). [[Violation story – no blanket copyrights]] Compliance Management: responsible to ensure CS licensed software is not distributed without Distribution/Provider (ASP, SPLA, or ASL) license grant and OS licensed software is not distributed without OSS code loaded for offer responses and appropriate OS license text. Individual OSS contributors – These are members of the OS communities. Invite them to the table. To get the most out of OS, the community needs to be engaged. Some of the organization’s developers may be OS members. Recommend having non-employees as well for buy-in (as well as viral marketing potential). IT Management: Discovery & reporting of OSS across the organization (Open Logic, Black Duck) that may not have been disclosed by developers or CS software vendors. Purchasing/ Supplier Management: Ensure that all software vendors, whether CS or OS, have IP transparency and communicate their OSS culture and program. Requesting a vendor’s OSS governance as part of the RFP. This is akin to supply-chain management. We need to understand the OSS culture of any code providers to assess whether they mesh with our OSS culture and policy and negotiate appropriate terms to ensure on-going alignment and audit. Keep the OSS enthusiasts in check. The lowest cost solution (when paid support is needed) is not always OS and not having paid support for critical systems (OS or CS) can be costly. **Linux Foundation's Self-Assessment Checklist good resource to assess OSS management readiness Is there a defined OSS policy and SOP in your organization? Is OSS mentioned as part of IP and confidentiality training and incorporated into Information Security Policy and IT Compliance policy? Every organization is using OSS whether they are aware or not. “Just say No” is not a reasonable or prudent policy stance.
- Here is a simple policy recommendation. It hinges on the fact that all software is copyrighted warranting monitoring of its use, whether OS or CS. Noncompliance can be costly. Fees and fines from CS copyright owners. Public OS community ire by OS copyright owners (and fines for on-going noncompliance) So the policy makes no distinction about source of the code. We need to track in either case. It makes a small distinction between code in our products to be distributed in the 1st paragraph. The 2nd paragraph speaks to general copyright monitoring. We want the policy to allow us to “Just say yes” and leverage OS and CS options depending on the situation. It should be the copyright management process at distribution, not the policy or code management process that makes the difference between OS and CS.
- Open Source resources are wide and open, literally. Here are just a few. Open Source Institute is a nonprofit founded in 1998 that educates about, advocates for, and quasi-regulates the open source communities worldwide. One of the biggest benefits for the procurement professionals was the 2006 Proliferation Project, where the 60+ different OS license terms (and their variations) were analyzed and nine (9) were identified as widely used with strong OS communities to support them. Understand the nuances and criteria of these 9 to become a master OR just go to the site to read them when reviewing terms of a deal. Free Software Foundation – are OS enthusiasts. Linux Foundation’s Open Compliance Program - is supported by mainstream IT Gpl-violations, despite its name, gives some balanced advise on complying with OS copyright and engaging the OS communities. BlackDuck Software and OpenLogic are competitors who maintain robust blogs on OS.