About the Android Open Source Project Android is an open source software stack for a wide range of mobile devices and a corresponding open source project led by Google. This site and the Android Open Source Project (AOSP) repository offer the information and source code you need to create custom variants of the Android stack, port devices and accessories to the Android platform, and ensure your devices meet compatibility requirements. We also wanted to make sure there was no central point of failure, where one industry player could restrict or control the innovations of any other. The result is a full, production-quality operating system for consumer products with source code open for customization and porting. Complete Site Redesign This site has been overhauled to make it easier for you to navigate, search, and read its ever-growing set of information. Find new tabs, footers, reference materials, and more. Security Year in Review The Android Security team has published its 2016 Year In Review. This comprehensive report describes the measures Android and Google take to keep users safe. March Android Security Bulletin The March 2017 Android Security Bulletin has been published along with links to associated fixes and new build numbers to support the March Android security release.

Read more from the original source:
Android Open Source Project

Open source software has evolved from providing low-cost alternatives to proprietary offerings to a platform for innovation, according to Red Hat CEO Jim Whitehurst.

Learn how to successfully adopt a DevOps in your organisation as well as how to improve the agility of the team and draw inspiration for your DevOps project from 3 case studies.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Over the last five years, most developments in big data, cloud and software-defined networking is happening first in open source, Whitehurst said during a media briefing in Singapore, adding that innovations by Internet giants such as Google and Facebook are largely based on open source platforms.

It is not just about saving money now, it is about enabling new capabilities to solve new business problems," he said.

Last year, a Red Hat-commissioned study by analyst house Forrester revealed that 52% of 455 CIOs and senior IT decision makers in the Asia-Pacific (APAC) region are already tapping open source software in areas such as cloud, mobility, big data and DevOps.

Forrester noted that IT leaders in APAC also see open source as a strategic investment, not just a cost-saving option.

Against this backdrop, Whitehurst said every company would now need to have an open source strategy, particularly in how open source software can be used to transform businesses.

Digital transformation is about technology enabling fundamental changes to an organisation, he said. But with business models changing so quickly and a massive amount of ambiguity, businesses have to rethink how they enable themselves to survive.

Whitehurst said although traditional businesses may develop and execute strategies to transform themselves, the world is moving too fast for any organisation to put up any meaningful five-year plan.

Who would have thought that Ford and General Motors would need to worry about Uber in a couple of years? And in the airline industry, people worry about Google having access to your calendar and proposing a better travel experience from another airline that meets your need, he said.

In addressing such concerns, Whitehurst said companies should plan less, not more, and focus on building capabilities so they can respond more quickly to change.

Whitehurst said some of the largest companies in the world are turning to Red Hat not for its technology, but because of the open source companys strong participation in communities and the ability to identify innovations that benefit businesses.

Everything we do is powered by participation, he said. Every line of code we put out there to the decisions we make, are done in an open way. We are radically open in how we try to solve problems, and that has made us successful.

Whitehurst also claimed that some organisations are doing open source in name only.

One of the issues with open source is that it technically defines a set of licences around software, so there are vendors that give away source code but are not building broad participation, he said.

Or, if you take something thats open source but not driving things upstream so that all your contributions can be consumed, youre not helping to drive open source forward, he added.

As an example, Whitehurst said that over 90% of the contributions to Cloud Foundry, which competes with Red Hats OpenShift, come from one company and not its users.

Theres nothing wrong with something like Cloud Foundry its just that its open source in licence only and not really an open source community, he said.

In an interview with Computer Weekly earlier this year, Cloud Foundrys executive director Abby Kearns said the number of community members has grown since the Cloud Foundry Foundation was created in 2015.

The foundation is also gearing up to woe more developers to the platform-as-a-service (PaaS) offering this year.

Follow this link:
Open source adoption in APAC no longer just about cost-cutting - ComputerWeekly.com

Our digital lives are powered by programming philosophers who choose to develop their code out in the open.

All programs begin with lines of instruction. When ready for execution these lines of instruction are converted to a binary format that the computer can execute. Open source programs are programs where the human readable code is accessible to anyone. This philosophy of openness and freedom has allowed these projects to impact the lives of everyone.

The Linux kernel is the core of all Android devices, and nearly a third of all Internet traffic rides on just one openly developed project, Netflix. (Read the excellent article in Time magazine about this.) How does the choice of using open source software as part of a project plan affect the amount and type of risk to a project within an organization?

Risk is both a perception and a reality. Tools help us move from perception toward reality the same way good thermometers helped us move from very generalized use of the terms hot and cold to more specific quantifiable temperatures (see an example in Google). Over time we've adopted different standards and techniques for discussing specific temperatures, whichdependon the audience and the standard's limitations. Kelvin, Celsius, Fahrenheit, and even RealFeel are now established standards for measuring temperature.

Illustration 1: Quantifying temperatures

Every project has risk and every PM (project manager) perceives and articulates that risk differently with various levels of accuracy. The understanding of risk may be as simple as a good or bad description similar to the terms hot and cold. The PMBOK (Project Management Body of Knowledge) states that the process for discussing risk management should move from a qualitative evaluation to a quantitative one (as stated in the Project Management Institute's publication, "A guide to the project management body of knowledge/PMBOK Guide" (5th ed.)). Like temperature, the discipline of project management has different quantifiable standards for measuring project risk. At least one of these standards for risk evaluation communicates why open source software is often rejected as a possible consideration for projects during the project planning process.

The Risk Complexity Index discussed in Tom Kendrick's book Identifying and Managing Project Risk(Kendrick, 2015) serves as our foundation. Complexity indexes aren't uncommon in project risk management. David Bearden used a complexity index to show how NASA's adoption of its FBC (Faster, Better, Cheaper) philosophy has impacted project risk. While his index is based upon near recent data points, the risk complexity index in Kendrick's book attempts to be more predictive. Kendrick articulates the formula for the index as:

Index = (Technology + Architecture + System) X Scale

Technology, Architect, and System are scored from 0 to 5, based on the PM's experience and capabilities. "Architecture refers to high-level functional components and any external interfaces, and System is the internal software and hardware that will be used in the product. The Technology dimension is defined as the basis for development used on the project," Kendrick said in his book. He explains that the Index could be scored using the following key:

0. Only existing technology required 1. Minor extensions to existing technology needed in a few areas 2. Significant extensions to existing technology needed in a few areas 3. Almost certainly possible, but innovation needed in some areas 4. Probably feasible, but innovation required in many areas 5. Completely new, technological feasibility in doubt

Scale is assigned a value based on the number of people expected on the project:

In this index a result of 0 to 20 is considered low risk, 20 to 40 is medium risk, while the range from 40 to 100 is high risk. Just as a price tag is a summary of the cost of production elements for a given item on the grocery store shelves, this index is a summary of items that contribute to project risk. At this point of risk management, the risks have been identified and quantified. Initially, the entire risk index refers to the risk of the project internal to the organization conducting it. After mitigation measures are developed the project can be re-scored with the matrix.

Scoring risk

In Adrienne Watt's chapter in the book Risk Managementon risk management planning, she discusses four strategies for mitigating risk. These are risk avoidance, risk sharing, risk reduction, and risk transfer. After applying some combination of these strategies, the PM team can rework the risk complexity index to determine if they reduced the project's overall risk to an acceptable level.

The key issue with open source is that when it is used, the risk is assumed by the organization. Open source code licenses such as BSD's very brief license includes language expressly transferring the responsibility from the code's originators to the code's users. It does this through its statement that "this software is provided 'as is' and without any express or implied warranties." For Linux, the GPL 3.0 preamble states, "for the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software" (Free Software Foundation, 2007).

This undermines several key aspects of the mitigations listed previously. If the organization assumes technical responsibility for the code, they have a reduced capacity to avoid, share, reduce or transfer the risk. Open source code can still be a part of the solution for a risk management strategy and in some cases, open source code is a huge factor in mitigating risk.

Software from major vendors includes the added risk of the strategy tax for that vendor. The strategy tax associated with Microsoft Windows reached a critical point with Valve, the creator of Steam, a popular game distribution platform. Valve chose to mitigate the increased risk and developed SteamOS, which ported their distribution software to run on open sourced code (Dingman, 2013). The code they chose for their foundation has a much lower strategy tax, significantly reducing their risk.

While Valve's talent pool of programmers meant they had the technical knowledge to audit and understand the relevant source code, not every business is as well resourced. Businesses that do have a sizable number of programmers tend to incorporate open source applications into their project planning. In 2010, Google switched a large number of their machines from Windows to Linux. Netflix runs FreeBSD to take advantage of the technology built into ZFS.

Brand value plays a large role in a business asset portfolioand projects that could damage that brand can be viewed as putting the company at higher risk. One of the more sensitive brand sectors is that of IT Security firms who work projects for each one of their clients. From my private conversations with employees from this sector, I've learned that one way they transfer their risk is through policies on company communications channels. Precisely none of their communications channels are internal. Instead, each employee is required to use multiple external communications technologies. The organization's reality is that if their brand becomes victim to a successful attack and any part of the news cycle includes the organization's name, this causes severe damage to the brand, so for email they use Gmail and for chatthey use Slack (Pen Testing, 2016). They rely on a myriad of other applications and services to reduce their attack surface and transfer risk to as many organizations as possible.

The true cost of risk to a project doesn't end at project completion but rather with customer satisfaction throughout the product's lifecycle. To precisely illustrate brand risk from open source projects the recent past contains a poignant example. When Trend Micro's team conducted a project to build their organization's website they chose the popular open source WordPress suite. Recently, WordPress had a vulnerability that was exploited by hackers and received mostly positive attention for its measured response to patch this vulnerability. In contrast, Trend Micro's site received similarly bad press (McCaskill, 2017 and JupiterBroadcasting, 2017) from the decisions of earlier project managers.

With this type of negative press surrounding open source, it's no wonder why many PMs overlook the advantages open source may have in actuallyreducing the complexity index for a project. KDE's website recently published an interview with a Thomas Weissel, a developer working for the Austrian school system who concluded a project to incorporate KDE into the Austrian school where he worked. In the interview, he describes one critical advantage for open source, the accessibility of the team to resolve issues. In his words:

"That's yet another reason why I picked Plasmashell: The KIOSK system. I reported a lot of issues with the KIOSK system and Plasma developers did an amazing job finding and fixing all the bugs I've found for 5.8. We now have a desktop that is completely locked to make sure nobody accidentally removes or reconfigures important parts of the user interface," said Weissel(Riddell, 2017).

Chris Fisher, a long-time open source commenter, rhetorically asked PMs how long they believed it would take a closed source vendor to respond to identified bugs during a project's execution. This is a terrific example of architecture cost being shifted from the organization to the developers. For enterprise-scale projects, large, closed sourced vendors may be willing to work with their clients. For smaller-scale projects, the responsiveness of a project team may be their only way to tool the software to their specific needs.

Open source solutions have been adopted by various sectors of the market to fit key roles in our technology infrastructure. The risk complexity index developed by Tom Kendrick helps us to understand the difficulties with the adoption of open source solutions across all dimensions of the market.

In general, open source solutions shift the risk from a software vendor to the organization. In today's environment where branding is both costly and crucial, open source solutions represent a direct risk to the brands who use them. Despite this risk, many large- and small-scale projects are still choosing open source solutions for projects where the complexity index is reduced by their implementation. The example of the KDE development team working with a small project manager in Austria to develop the best code possible is a clear example of a significant advantage within the field of open source. While the authors of the code may not be legally liable, their pride in their product generally serves as a terrific motivator for them to deliver their best.

Kendrick, T. (2015). Identifying and managing project risk: essential tools for failure-proofing your project. New York: American Management Association.

Pen Testing [Personal interview]. (2016, December).

Project Management Institute (PMI, 2013). A guide to the project management body of knowledge/PMBOK Guide (5th ed.). Newton Square, Pennsylvania: Project Management Institute, Inc.

Read more from the original source:
Understanding the difficulties of the adoption of open source ... - Opensource.com

Talk about starting a business based on open source software and the conversation will inevitably shift to Red Hat. That's because the Linux vendor is a shining example of a company that's making money from an open source product. But how easy is it really to establish an open source startup that makes money? For every success story like Red Hat there are companies like Cyanogen that fail to thrive and projects that are abandoned.

It's tempting to believe that the Red Hat business model, which is based around selling subscriptions for support to a maintained and tested version of Linux (or a closely related model that offers consultancy and customization to an open source software solution as well support and maintenance), is the most viable way to make money from open source software. But Sam Myers, a principal at Balderton Capital, a technology venture capital company, says that most open source startups are unlikely to succeed using these business models.

[ What CIOs don't know about open source software ]

"Despite Red Hat, it is actually quite challenging to make money selling customization, support and consultancy," Myers says. "Why? Because it is head-count driven, the model doesn't scale, and you get low renewals. And you have competition from other consultancies."

Myers admits that the subscription model can occasionally be successful, but asserts that a more promising business model is to build a product line around an open source core. This can involve developing premium software modules that add features to the core open source software or, alternatively, building supporting applications that complement the core.

SuiteCRM, for example, offers its open source CRM software for free but charges for modules like an Outlook plugin. "What can upset people is when you develop new code that makes the core better but keep it proprietary, but if you build apps that work on top of it then there is no issue there," says Myers.

Another open source startup business model involves offering hardware that is suited to the software (in the way that Digium sells telephony hardware to run the open source Asterisk telephony software.) But Myers warns that this model can be difficult to sustain because customers typically only buy the hardware occasionally. Instead, he recommends looking for a business model that produces a recurring revenue stream. These can include offering open source software as a service or charging for API use in addition to selling premium modules or supporting applications as mentioned above.

[ The top 8 new open source projects ]

What quickly became apparent from speaking with Myers is that there is no "best" open source business model, and Allison Randal, president of the Open Source Initiative, says that open source startups should avoid searching for one. "The mistake people make is thinking about an open source business model. They should be thinking about a business model and how open source software fits into that," she says. "VCs are only beginning to understand open source and how to make money, but the way is the same as for any other business: by offering better value and making customers happy. "

A defining feature of many open source projects is the community that surrounds them, and there is always a danger that a company seeking to make money from open source software may alienate that community. That's because members of the community may feel that their volunteer efforts are being exploited for someone else's financial gain. So how much consideration should open source startups give to the project's community?

In some instances, like when a company provides almost all of the code commits to a project, Myers says that not much consideration needs to be given to community. "The main benefit of open source software isn't necessarily that development is crowdsourced. In some cases, something needs to be open source so that companies that use it don't have to be worried about vendor lock in," he says.

But in many cases there are great benefits to be had from adopting a business model that involves fostering an active community. "If you are looking for commits from outside then it is important to focus on the community, both to get developers working on code and also to see who your users are, because these are your leads for upselling."

Myers warns that communities don't just spring up and thrive by themselves though, so it's vital for an open source startup to spark interest in the community through marketing and communication. Avoiding alienating the community in the way that Cyanogen Inc. did when it decided to monetize the community's work communication is especially important, he says.

[ Open source: Career-maker, or wipeout? ]

What kind of marketing and communications are necessary? "You need to make sure that you say that X percent of your resources will be devoted to developing the open source project and Y percent will go to developing the proprietary modules or other applications that you plan to sell," says Myers. "If you can manage to do that successfully then you can manage any perceived conflict of interest."

Alex Freedland, CEO of Mirantis, a company that has built a business around the open source OpenStack cloud operating system, says that to foster widespread adoption of an open source product you need an ecosystem around it, and to get that you also need a strong community. For that reason, he says, Mirantis makes a point of ensuring its contributions to a project never exceed 25 percent of the total in a given time frame.

Freedland also says that the community should trump the business when it comes to choosing the direction software development should take. "You need to decide what is of benefit to the community and do it, even if it goes against the short-term interests of the company," says Freedland. "It is also important that community members feel they won't be punished for their actions you need to foster a culture where community members can do whatever they feel will benefit the community."

He also advocated that open source companies devote a proportion of their resources to seeding other groups to expand the ecosystem.

Myers says there are two mistakes that open source startups that want to make money should make a point of avoiding. "If you just take the community's code (and build proprietary modules around it) then you are bound to alienate the community, and I can't see that ending well," he says. "And another mistake is trying to charge too soon for premium versions before a project has a strong community around it. You need to build a large audience for an open source software project before you can start to monetize it."

The Open Source Initiatives Randal says that while most communities don't mind a company trying to monetize a project, it is key that the community still has a life of its own in the way that Red Hat has fostered the Fedora community. "What drives a community away is when you take the wind out of its sails and it feels taken over," she says. Randal adds that little things can make a big difference: if Cyanogen Inc. had chosen a different name (in place of Cyanogen OS) for its commercial product, which was based on the Cyanogen Mod project, then the community may not have felt so offended by it, she says.

Mirantis Freedland adds that open source projects should be run as meritocracies and remain open to new ideas because startups that try to micromanage the direction of a project are inevitably on the path to failure. "There are always religious zealots, but as the leader of a startup you need to limit your own influence. If you do that you won't alienate the community, but if you don't then it will come back to bite you in the end."

See more here:
How to make money from open source software | CIO - CIO

An abandoned mattress may be free to use, but without knowing where it came from, would you want to?

When open source first started to become mainstream in the 90s, there was a good deal of debate about what 'free software' meant.

It wasn't just about something you didn't have to pay for, went the philosophy, it was also about being able to see the source code to understand what was going on, and to make your own changes.

'Free' as in speech, not 'free' as in beer, went the motto.

That's a good start, but it doesn't really go far enough; free speech has consequences but they're not the first thing people think of when you say that. The argument that 'all bugs are trivial when you have enough eyeballs' assumes that all those eyeballs belong to people who are looking, understanding, and contributing.

In a lot of cases, many eyeballs are shallow eyeballs, because everyone assumes that someone else has done the hard work of understanding the code. And as open source becomes widely used, there are many more people using open source code who aren't going to be expert coders in the language a particular project is written in -- if they're coders at all.

So I started saying that open source was also 'free as in puppy'. Yes, it looks cute, but when you bring it home you have to feed it, exercise it, clean up its messes and take responsibility for it. And when it grows up, that puppy may not be the small, cute, little project you saw in the window, so you need to look into the pedigree of that puppy.

As open source has become more important commercially, a lot more people have started talking about 'free as in puppy' -- because any software you pick up and incorporate into your business or your development workflow brings with it responsibilities. Key open source software that an entire industry relies on has been critically underfunded for decades; the Linux Foundation's Critical Infrastructure projects are an attempt to redress this, because it doesn't just happen on its own.

If you were using FoundationDB because you thought it was open source like the other NoSQL databases, because you'd never read the licence, you would have got a rude shock when Apple bought the company and pulled all the code from GitHub. Turns out it was only some code to help you use the proprietary database code that was actually open source.

If the open source puppy makes things sound too appealing, I sometimes say 'free as in mattress'. As in, there's a mattress leaning up against a wall, and anyone can take it home -- but without knowing where it came from, would you want to?

Now, open source is becoming so widely used that open source creators and maintainers are starting to feel the strain, not least because not all new open source users are polite, friendly, and considerate (nor indeed, are all experienced open source users).

It's great to report a bug in an open source project, or even write up some code to fix it and submit that as a pull request. But whether it's the sheer volume of reports, the users who are rude and demanding when they give feedback or criticize the direction of the open source project, the would-be contributors who offer code that doesn't fit the long-term direction of the project or just increases the maintenance work for the project, open source creators and maintainers are starting to talk about overload and burnout, self care, and prioritization.

It's a tragedy of the commons, because individuals don't scale the way technology does.

The usual answer is to suggest how important it is to have a community (formal or informal) around projects to share that load, but it's easy to forget how hard it is to build and nurture those communities. Look at the Node.js contribution policy to see how much work it takes to run a large community.

If you're working on building an open source community, take a look at Nadia Eghbal's (free) book, Roads and Bridges: The unseen labour behind our digital infrastructure.

Seeing the latest discussions about how widely unappreciated the work to maintain open source is made me add another free to my list: free as in 'night off'.

There's a reason that commercial software companies don't only have developers -- they have testers, support teams, marketers, and an entire ecosystem supporting the coders. A lot of larger open source projects are sponsored by or interlinked with commercial companies, because that ecosystem can be a thriving business, as well as taking a load off the coders.

Not everyone wants to add a commercial aspect to their open source project, so we need a wide range of models to make this work. But if we're not thinking about all the meanings of 'free' for open source, we're going to keep seeing unintended but very predictable consequences for code that we're all coming to depend on.

See more here:
Open source: Free as in beer, puppy... or mattress? - ZDNet

Talk about starting a business based on open source software and the conversation will inevitably shift to Red Hat. That's because the Linux vendor is a shining example of a company that's making money from an open source product. But how easy is it really to establish an open source startup that makes money? For every success story like Red Hat there are companies like Cyanogen that fail to thrive and projects that are abandoned.

It's tempting to believe that the Red Hat business model, which is based around selling subscriptions for support to a maintained and tested version of Linux (or a closely related model that offers consultancy and customization to an open source software solution as well support and maintenance), is the most viable way to make money from open source software. But Sam Myers, a principal at Balderton Capital, a technology venture capital company, says that most open source startups are unlikely to succeed using these business models.

[ What CIOs don't know about open source software ]

"Despite Red Hat, it is actually quite challenging to make money selling customization, support and consultancy," Myers says. "Why? Because it is head-count driven, the model doesn't scale, and you get low renewals. And you have competition from other consultancies."

Myers admits that the subscription model can occasionally be successful, but asserts that a more promising business model is to build a product line around an open source core. This can involve developing premium software modules that add features to the core open source software or, alternatively, building supporting applications that complement the core.

SuiteCRM, for example, offers its open source CRM software for free but charges for modules like an Outlook plugin. "What can upset people is when you develop new code that makes the core better but keep it proprietary, but if you build apps that work on top of it then there is no issue there," says Myers.

Another open source startup business model involves offering hardware that is suited to the software (in the way that Digium sells telephony hardware to run the open source Asterisk telephony software.) But Myers warns that this model can be difficult to sustain because customers typically only buy the hardware occasionally. Instead, he recommends looking for a business model that produces a recurring revenue stream. These can include offering open source software as a service or charging for API use in addition to selling premium modules or supporting applications as mentioned above.

[ The top 8 new open source projects ]

What quickly became apparent from speaking with Myers is that there is no "best" open source business model, and Allison Randal, president of the Open Source Initiative, says that open source startups should avoid searching for one. "The mistake people make is thinking about an open source business model. They should be thinking about a business model and how open source software fits into that," she says. "VCs are only beginning to understand open source and how to make money, but the way is the same as for any other business: by offering better value and making customers happy. "

A defining feature of many open source projects is the community that surrounds them, and there is always a danger that a company seeking to make money from open source software may alienate that community. That's because members of the community may feel that their volunteer efforts are being exploited for someone else's financial gain. So how much consideration should open source startups give to the project's community?

In some instances, like when a company provides almost all of the code commits to a project, Myers says that not much consideration needs to be given to community. "The main benefit of open source software isn't necessarily that development is crowdsourced. In some cases, something needs to be open source so that companies that use it don't have to be worried about vendor lock in," he says.

But in many cases there are great benefits to be had from adopting a business model that involves fostering an active community. "If you are looking for commits from outside then it is important to focus on the community, both to get developers working on code and also to see who your users are, because these are your leads for upselling."

Myers warns that communities don't just spring up and thrive by themselves though, so it's vital for an open source startup to spark interest in the community through marketing and communication. Avoiding alienating the community in the way that Cyanogen Inc. did when it decided to monetize the community's work communication is especially important, he says.

[ Open source: Career-maker, or wipeout? ]

What kind of marketing and communications are necessary? "You need to make sure that you say that X percent of your resources will be devoted to developing the open source project and Y percent will go to developing the proprietary modules or other applications that you plan to sell," says Myers. "If you can manage to do that successfully then you can manage any perceived conflict of interest."

Alex Freedland, CEO of Mirantis, a company that has built a business around the open source OpenStack cloud operating system, says that to foster widespread adoption of an open source product you need an ecosystem around it, and to get that you also need a strong community. For that reason, he says, Mirantis makes a point of ensuring its contributions to a project never exceed 25 percent of the total in a given time frame.

Freedland also says that the community should trump the business when it comes to choosing the direction software development should take. "You need to decide what is of benefit to the community and do it, even if it goes against the short-term interests of the company," says Freedland. "It is also important that community members feel they won't be punished for their actions you need to foster a culture where community members can do whatever they feel will benefit the community."

He also advocated that open source companies devote a proportion of their resources to seeding other groups to expand the ecosystem.

Myers says there are two mistakes that open source startups that want to make money should make a point of avoiding. "If you just take the community's code (and build proprietary modules around it) then you are bound to alienate the community, and I can't see that ending well," he says. "And another mistake is trying to charge too soon for premium versions before a project has a strong community around it. You need to build a large audience for an open source software project before you can start to monetize it."

The Open Source Initiatives Randal says that while most communities don't mind a company trying to monetize a project, it is key that the community still has a life of its own in the way that Red Hat has fostered the Fedora community. "What drives a community away is when you take the wind out of its sails and it feels taken over," she says. Randal adds that little things can make a big difference: if Cyanogen Inc. had chosen a different name (in place of Cyanogen OS) for its commercial product, which was based on the Cyanogen Mod project, then the community may not have felt so offended by it, she says.

Mirantis Freedland adds that open source projects should be run as meritocracies and remain open to new ideas because startups that try to micromanage the direction of a project are inevitably on the path to failure. "There are always religious zealots, but as the leader of a startup you need to limit your own influence. If you do that you won't alienate the community, but if you don't then it will come back to bite you in the end."

This story, "How to make money from open source software" was originally published by CIO.

See the article here:
How to make money from open source software | ITworld - ITworld

Thank you

Your message has been sent.

There was an error emailing this page.

Teradata today released its data lake management software platform to the open source community. The project aims to help organizations address common challenges in data lake implementation, including skill shortages for engineers and administrators, learning and implementing governance best practices and driving data lake adoption beyond engineers.

Teradata is offering the new open source Kylo project under the Apache 2.0 license, and plans to offer services and support for the platform.

Kylo evolved from code developed by Teradata company Think Big Analytics over eight years of engagements with Fortune 1000 customers on more than 150 data lake projects. It was built using open source capabilities including Apache Hadoop, Apache Spark and Apache NiFi.

[ Related: 15 data and analytics trends that will dominate 2017 ]

"Open source software has an appeal to users seeking independence, cooperative learning, experimentation and flexibility for customized deployments, Rick Farnell, president of Think Big, said in a statement today.

Teradata says data lakes take too long to build, and in the average six to 12 month build cycle, users find that use cases often become out of date. In addition, while the software costs associated with data lakes may be lower, Teradata says engineering costs can mount quickly. When data lakes are successfully created, users often find them difficult to explore.

Teradata says Kylo will help organizations address these challenges, because it integrates and simplifies pipeline development and common data management tasks. That means organizations that leverage Kylo achieve faster time-to-value and greater user adoption and developer productivity. Teradata says Kylo doesn't require coding, and it offers an intuitive user interface that enables self-service data ingest. Meanwhile, reusable templates help increase productivity.

[ Analytics 50: Call for 2017 entries ]

One major telecommunications company recently implemented Kylo after a large team of 30 data engineers spent months hand-coding data ingestion pipelines. With Kylo, a single individual was able to ingest, cleanse, profile and validate the same data in less than a week, Teradata says.

The Kylo software, documentation and tutorials are now available via the Kylo project website and via the GitHub website. Think Big is offering optional services around Kylo including the following:

Thor Olavsrud covers IT security, big data, open source technology, Microsoft tools and servers for CIO.com.

Sponsored Links

Read the original post:
Teradata releases data lake platform to open source - CIO

Short Bytes:Kerala adopted Free and Open Source Software in 2005 in a phased manner and went on to replaceproprietary software. As a result, Kerala annually saves $58 million (Rs 300 crore). Thanks to the Free Software license, people are able to freely copy and distribute the software.

Having said that, weve told you numerous stories that involved European cities and countries choosing open source software. But, today, Im going to tell you about an Indian state that has been doing so for a long time.

In Kerala, IT became a compulsory subject in 2003. It was followed by the phased adoption of Free and Open Source Software (FOSS) in 2005. This was done to replace the proprietary software.

K. Anwar Sadath, executive director [emailprotected], said that they have been given the job for easy classroom teaching, teachers training, and customization ofapplications, reports AINS.

Mr. Sadath said that theproprietary version of asoftware would have incurred a minimum cost of Rs 150,000 per machine in terms of thelicense fee.Considering the 20,000 machines, the annual saving is minimum Rs 300 crore ($58 million). He further adds that the free nature of FOSS allows the people to copy and share software without any restriction.

Kerala IT News reports that Ubuntu Linux is loaded in all laptops and desktops for school. Also, the revised textbook would include GNUKhata as a replacement for Tally and LibreOffice as a replacement for Microsoft Office.

Do you have some interesting local story regarding the adoption of open source software? Feel free to share it with us and we might feature it on Fossbytes.

Bonus Video: 10 InterestingLinux Facts

View original post here:
Indian State of Kerala Saves $58 Million Each Year By Using Free And Open Source Software - Fossbytes

It is now pretty well accepted that open source is a superior way of producing software. Almost everyone is doing open source these days. In particular, the ability for users to look under the hood and make changes results in tools that are better adapted to their workflows. It reduces the cost and risk of finding yourself locked in with a vendor in an unbalanced relationship. It contributes to a virtuous circle of continuous improvement, blurring the lines between consumers and producers. It enables everyone to remix and invent new things. It adds up to the common human knowledge.

And yet, a lot of open source software is developed on (and with the help of) proprietary services running closed-source code. Countless open source projects are developed on GitHub, or with the help of JIRA for bug tracking, Slack for communications, Google Docs for document authoring and sharing, Trello for status boards. That sounds a bit paradoxical and hypocriticala bit too much "do what I say, not what I do." Why is that? If we agree that open source has so many tangible benefits, why are we so willing to forfeit them with the very tooling we use to produce it?

The argument usually goes like this: Those platforms may be proprietary, they offer great features, and they are provided free of charge to my open source project. Why on Earth would I go through the hassle of setting up, maintaining, and paying for infrastructure to run less featureful solutions? Or why would I pay for someone to host it for me? The trick is, as the saying goes, when the product is free,youare the product. In this case, your open source community is the product.

In the worst case scenario, the personal data and activity patterns of your community members will be sold to third parties. In the best case scenario, your open source community is recruited by force into an army that furthers the network effect and makes it even more difficult for the next open source project to not use that proprietary service.

In all cases, you, as a project, decide to not bear the direct cost, but ask each and every one of your contributors to pay for it indirectly instead. You force all of your contributors to accept the ever-changing terms of use of the proprietary service in order to participate in your "open" community.

It is important to recognize the situation for what it is: a trade-off. On one side, shiny features and convenience. On the other, a lock-in of your community through specific features, data formats, proprietary protocols or just plain old network effect and habit.

Each situation is different. In some cases, the gap between the proprietary service and the open platform will be so large that it makes sense to bear the cost. Google Docs is pretty good at what it does, and I find myself using it when collaborating on something more complex than Etherpads or Ethercalcs. At the opposite end of the spectrum, there is reallynoreason to use Doodle when you can use Framadate. In the same vein,Wekanis close enough to Trello that you should really consider it as well. For Slack versusMattermostversus IRC, the trade-off is more subtle.

As a side note, the cost of lock-in is a lot reduced when the proprietary service is built on standard protocols. For example, Gmail is not that much of a problem because it is easy enough to use IMAP to integrate it (and possibly move away from it in the future). If Slack was just a stellar opinionated client using IRC protocols and servers, it would also not be that much of a problem.

Any simple answer to this trade-off would be dogmatic. You are not unpure if you use proprietary services, and you are not wearing blinders if you use open source software for your project infrastructure. Each community will answer that trade-off differently, based on their roots and history.

The important part is to acknowledge that nothing is free. When the choice is made, we all need to be mindful of what we gain, and what we lose. To conclude, I think we can all agree that all other things being equal, when there is an open source solution which has all the features of the proprietary offering, we all prefer to use that. The corollary is, we all benefit when those open source solutions get better.

So to be part of the solution, consider helping those open source projects build something as good as the proprietary alternative, especially when they are pretty close to it feature-wise. That will make solving that trade-off a lot easier.

This article was originally posted on ttx:reloaded and was reposted with permission under a CC BY-SA 4.0 license.

Read this article:
Using proprietary services to develop open source software - Opensource.com

Informed news analysis every weekday

Your message has been sent.

There was an error emailing this page.

HackerOne is bringing bug hunting and software testing to open source developers to help make open source software more secure and safer to use.

A lot of modern tools and technologies depend on open source software, so a security flaw can wind up having a widespread impact -- the Heartbleed flaw in OpenSSL, for example. Many open source projects still rely on the "thousand eyes" concept when it comes to software security -- that anyone being able to see the source code means defects are found and fixed faster. While it's true to some extent, it doesn't apply if no one is actually looking at the code, as we've learned repeatedly over the past few years.

HackerOne's platform helps software teams put together a comprehensive vulnerability management program, which is more than bug bounties alone. The platform helps teams handle vulnerability submissions, coordinate communications with involved parties, identify duplicate reports, and, yes, run bug bounty programs. All of these services are now available to open source projects for free as part of HackerOne Community Edition. Eligible projects must be covered by an OSI license and be at least three months old.

Core committers on an open source project don't always have the time to go hunting in the code looking for security vulnerabilities. They already have to triage bug reports, add or refine features, and test proposed patches. Security testing happens rarely or sporadically, and unless someone reports a vulnerability, these flaws typically linger for a long time.

HackerOne solves the visibility problem in open source security by giving those eyeballs a place to look. If people don't know about a particular project, then they won't look at the source code to find security flaws. Someone interested in bug hunting is more likely to pick from a list of projects that welcome vulnerability submissions than randomly picking one out of the ether. HackerOne Community Edition helps software teams "define scope, receive vulnerability reports, manage those reports, and incentivize security researchers" to help harden the project, the company said.

This kind of coordination improves open source security because it lets projects get actionable security reports they otherwise may never see. It's far better to have a coordinated process than to have the report posted on the full-disclosure mailing list or lose it because the researcher couldn't find the correct email address to send the information.

Eligible projects need to add a security.md file in the project root with details on how testers can submit vulnerabilities. To continue using HackerOne Community Edition, the project team members have to be able to respond to new reports in a timely manner -- in this case, less than a week.

The platform is free for the open source project owner, but HackerOne will still charge the usual 20 percent payment processing fee if the team has a program that pays out cash bounties for valid bugs. Customer service support isn't included in the Community Edition, but HackerOne promised a "wealth of documentation" online.

The visibility problem tackles only a part of the open source security challenge, since these vulnerabilities still need to get fixed. If the project is underfunded or under-resourced (or both), then getting the updates and patches out in a timely manner will still be a problem. However, getting the reports is still a good place to start.

HackerOne has been used by many companies to run public and private bug bounty programs, including Adobe, Kaspersky Lab, Twitter, Microsoft, and Facebook. Its services aren't limited to giant technology firms or commercial projects, either. To date, 36 open source projects, including Discourse, Django, and GitLab, have used HackerOne to power vulnerability management programs, addressing more than 1,200 vulnerabilities in their code.

Fahmida Y. Rashid is a senior writer at InfoWorld, whose coverage focuses on information security.

Sponsored Links

Link:
HackerOne opens up bug bounties to open source | InfoWorld - InfoWorld