Simon Phipps - Open Source Strategies for the Enterprise
Here you can read online Simon Phipps - Open Source Strategies for the Enterprise full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2012, publisher: OReilly Media, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Open Source Strategies for the Enterprise
- Author:
- Publisher:OReilly Media
- Genre:
- Year:2012
- Rating:4 / 5
- Favourites:Add to favourites
- Your mark:
Open Source Strategies for the Enterprise: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Open Source Strategies for the Enterprise" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
So youre thinking of creating an open source community around your code? Here are some things you ought to know before you make your plans too firm.
- Payment at the Point of Value: Open source is of course free software. But the freedom youre finding brings you value varies depending on the role you play with respect to the software. Free doesnt mean the same to everyone.
- Open Core Is Bad For You: The open core business model is popular with VC-funded startup companies but does not deliver the core freedoms from which lasting business value for customers is derived.
- Transparency and Privacy: The key success factor in an open source community is the equality of all the participants. A strong community is characterized by high levels of transparency about the project coupled with strong respect for the privacy of the participants. Read why you should not impose your business model on anyone.
Simon Phipps: author's other books
Who wrote Open Source Strategies for the Enterprise? Find out the surname, the name of the author of the book and a list of all author's works by series.
Open Source Strategies for the Enterprise — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Open Source Strategies for the Enterprise" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
\n
Beijing Cambridge Farnham Kln Sebastopol Tokyo
OSCONs theme last year was from disruption to default. Over the last decade, weve seen open source shift from the shadows to the limelight. Today, more businesses than ever are considering the role of open source in their strategies. Ive had the chance to watch and participate in the transitions of numerous businesses and business units to using open source for the first time, as well as observing how open source strategies evolve for software businesses, both old and new.
In the view of many, open source is the pragmatic expression of the ethical idea of software freedom, articulated in various ways for several decades by communities around both Richard Stallmans GNU Project and the BSD project. The elements of open source and free software are simple to grasp; software freedom delivers the rights to use, study, modify and distribute software for any purpose, and the Open Source Definition clarifies one area of that ethical construct with pragmatic rules that help identify copyright licenses that promote software freedom. But just as simple LEGO bricks unlock an infinite world of creativity, so these open source building blocks offer a wide range of usage models, which are still evolving.
This paper offers some thinking tools for those involved in the consideration and implementation of open source strategies, both in software consuming organizations and by software creators. It aims to equip you with transferrable explanations for some of the concepts your business leaders will need to consider. It includes:
A model for understanding the different layers of community that can form around an open source code commons and how you should (and should not) approach them.
An exploration of the symbiotic relationship of transparency and privacy in open source communities.
An explanation of where customer value comes from in enterprise open source, which illuminates the problems with open core strategies for communities and customers.
A reflection on the principle that can be seen at work across all these examples: trade control for influence
At every stage of the journey for businesses from the software adoption models that preceded the Internet to those that embrace it, I often find I need to distinguish between the different kinds of community that are layered around various free software commons. Community members are frequently characterised as either developers (the open source worldview often emphasizes this) or users (the free software worldview often emphasizes this). All the same, using the term community to apply to every style of gathering leads to confusion, especially regarding motivations for participating.
A free software commons is a body of software contained in some sort of repository usually a version control system but sometimes as simple as just a download directory and licensed under an OSI-approved open source license, with rules to determine who can modify the contents of the repository. There are also often other rules regarding use of trademarks, discussion forums and other resources, and there are also often rules concerning who may change some or all of the rules and how people gain the right to do so. All these rules are collectively termed the community governance. The subject of good governance is extremely important, but this section does not attempt to cover it.
As Ive watched various community engagements of many companies and individuals, and discussed this with various experienced open source practitioners, it seems to me that there are at least four different clearly differentiated software commons-centric community types, in two bands. These arent absolute classifications with hard-and-fast boundaries, and most communities span two of the types, but the distinction is helpful for enterprises when discussing communities.
This model is not suited to every kind of discussion, as there are other ways to think about community layers. Most notably, the model Im proposing here looks at the community layers from the outside , and it is also appropriate to use a model that looks from inside if the context is a community discussion. But the realisation that there is not just one open source community, nor even one kind of community, is a critical evolutionary step for enterprises wanting to engage in open source collaboration.
In the model Ive found useful for enterprise discussions, community types are layered around the free software commons like the layers of an onion.
From the centre outwards, the categories of community are in two groups:
Co-developer communities These are the people who directly engage with the core source code for the project. This is the place the project itself is made by a range of people who choose to synchronise an overlapping subset of their interests. Some of the people here may be paid to work on the project code, but all will be here because this is the code they want to work on.
Deployer communities These are the people whose main engagement with the code involves a running instance that is configured and deployed by the community members in conjunction with other software that forms a deployment environment or stack. While they will contribute bug reports, test cases, and occasional fixes, they dont write the project code themselves; they are experts at configuring, deploying and using it. They also may train other people to do so.
They can be further distinguished into two sub-categories each:
Co-developer communities:
Core co-developersThese are the people whose contributions implement, evolve and maintain the code in the commons. They will have broad permission to change sensitive parts of the code arising from their track record for excellence. They may also include people who specialise in designing the user experience for the software. Many of them will describe themselves as working on the project rather than working for their employer, and some of them may have worked on the same code for several different employers. They are likely to have a strong culture that youll want to approach with respect. Importantly, no-one has an automatic right to admission by or respect from this community, even though your company may be a major source of funding. Your star developer or program manager gets the same rights as anyone else, when she has earned them. Attempts at management control of any aspect of this community layer will be most unwelcome and will likely be considered as damage. Moreover, they wont welcome marketing messages, developer programmes and the like.
Font size:
Interval:
Bookmark:
Similar books «Open Source Strategies for the Enterprise»
Look at similar books to Open Source Strategies for the Enterprise. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Open Source Strategies for the Enterprise and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.