⁃	1) Agile Practices 
	⁃	Motivation —> illusion of predictability and forecast reliability
	⁃	Dreieck Modell (fixpunkte)
	⁃	Agile
	⁃	Kosten, Termin (fix), Scope (Schätzung, Variable)
	⁃	Wasserfall
	⁃	Scope (fix), Kosten, Termin (Schätzung, Variable)
	⁃	Agile Manifesto
	⁃	individuals and interaction OVER processes and tools
	⁃	Working Sofware OVER comprehensive documentation
	⁃	Customer Collaboration OVER contract negotiation
	⁃	Responding to change OVER following a plan
	⁃	Agile Practices Today and how ordered
	⁃	XP
	⁃	Scrum
	⁃	Product Backlog, Sprint backlog, Develop, Test, Wrap, Review, Adjust, daily meeting, release
	⁃	Kanban (work in progress should be smaller because of the visualization + problems should be visible there)
	⁃	workflow visualisieren
	⁃	Agile Practices in Corporate Environments
	⁃	Portfolio Approach
	⁃	unterschiedliche Sprint teams mit unterschiedlicher sprintdauer
	⁃	Typen
	⁃	Functional Silos
	⁃	Agile Teams
	⁃	Teams
	⁃	component team
	⁃	feature team
	⁃	Cross-team expert meetings
	⁃	Roles are important for success!!!
	⁃	Roles
	⁃	portfolio manager
	⁃	product owner (hat kundenverantwortung, verantwortlich für den wirtschaftlichen erfolg des produkts)
	⁃	Scrum master (leitet das scrum team, arbeiet normalerweise nicht mit, varantwortlich für den sprint)
	⁃	system team
	⁃	product manager (plant und managed ein oder mehr scrum teams mit dem scrum master)
	⁃	operations
	⁃	contracts
	⁃	fixed price project
	⁃	cooperation model (time and material)
	⁃	requirement engineering
	⁃	epics
	⁃	features
	⁃	user stories (small, one card, as who i want what so that why)
	⁃	INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)

	⁃	SAFE Framework (Full Enterprise Requirement Model —> see picture)
	⁃	Roles and Stories (picture)
	⁃	Testing
	⁃	types
	⁃	functional tests
	⁃	unit / component tests
	⁃	system quality tests
	⁃	system acceptance tests
	⁃	Controlling
	⁃	burn down chart
	⁃	SAFE (Self assesssment metrics)
	⁃	technical health, team health, sprint health, release health, product ownership health
	⁃	agile metrics (KPIs)
	⁃	velocity, burn down charts, cycle time, items per iteration, queue length, flow diagrams, ..
	⁃	Reviews / Audits
	⁃	Challenges and Risks
	⁃	change mgmt, team structure not clear enought, no clear roles, product owner role, process not imp
					implemented well (consequently), lack of transparency, team roles still focused on silos, inadequat impl

	⁃	2) Codeship

	⁃	3) Example Project
	⁃	Dependable Software
	⁃	integrative concept that ecompasses (attributes):
	⁃	availability
	⁃	reliability
	⁃	safety
	⁃	confidentiality
	⁃	integrity
	⁃	maintainability
	⁃	dependability tree (important)
	⁃	means
	⁃	fault prevention
	⁃	fault tolerance
	⁃	fault removal
	⁃	fault forecasting
	⁃	threats
	⁃	Error: “A difference…between a computed result and the correct result”
	⁃	Fault: “An incorrect step, process, or data definition in a computer program”
	⁃	Failure: “The [incorrect] result of a fault”
	⁃	error injection
	⁃	software aging
	⁃	reasons
	⁃	lack of movement
	⁃	ignorant surgery
	⁃	problems during lifecycle
	⁃	growth
	⁃	poor design
	⁃	error injection not done well
	⁃	preventive actions
	⁃	design and plan for change
	⁃	documentation and reviews
	⁃	plan for retierement and replacement
	⁃	Requirement Engineering
	⁃	Usability Engineering

	⁃	4) Release your stuff 3 times a day
	⁃	Dependendy Management
	⁃	problems when keeping libs in SCM instead of dependendcy tools (p. 5)
	⁃	difficult to manually find updated libs
	⁃	loose trace to source
	⁃	loose version information
	⁃	scm not built for versioning binaries (no diff, high resource usage)
	⁃	scm bad with large binaries
	⁃	tools: declare lib, version, where from, dependencies of the libs, auto retrieve, unique name and version
	⁃	maven, ivy, gradle
	⁃	Repository Management
	⁃	manage all third party dependencies and repos
	⁃	central location of created artifacts (no need to build always completely)
	⁃	proxy & cache remote repos (faster build times, easy traceability, fault tolerance)
	⁃	nexus, apache archiva, jfrog
	⁃	Build Management and Automation
	⁃	compile source code to binary
	⁃	package binaries
	⁃	execute test cases
	⁃	execute code analysis and reporting
	⁃	generate doc
	⁃	run app locally
	⁃	deploy app
	⁃	release and publish artifacts
	⁃	TOOL: GNU Make, Maven, Ant, Gradle
	⁃	Release Management
	⁃	Continuous Integration & Deployment
	⁃	Continuous Integration
	⁃	constantly merge dev with master and build & test automatically
	⁃	Principles by M. Fowler (IMPORTANT)
	⁃	maintain repo
	⁃	automate build
	⁃	make the build self testing
	⁃	everyone commits to baseline every day
	⁃	every commit should be built
	⁃	keep the build fast
	⁃	test in a production environment clone
	⁃	easy getting the last deliverable
	⁃	everyone can see the result
	⁃	automate deployment (mostly at night)
	⁃	Hudson/Jenkins, Apache Continuum, CruiseControl, Bamboo
	⁃	cloud edition: hosted externally, easy setup, good integration and scalability, BAD -> source code leaves the house
	⁃	Continuous Delivery
	⁃	continuously deliver your code to a staging environment for the customer to test
	⁃	Continuous Deployment
	⁃	automatic deployment from SCM to production (requires both integration and delivery)

	⁃	5) Five Challenges you solve for every project
	⁃	Transaction Management
	⁃	Models:
	⁃	Local Transaction Model (transactions are managed by the underlying database resource manager,)
	⁃	Programmatic Transaction Model (developer is responsible for managing the transaction)
	⁃	Declarative Transaction Model (the container environment takes care of starting, committing, and rolling back the transaction, Container Managed Transactions (CMT))
	⁃	Strategies
	⁃	Client Orchestration
	⁃	API Layer
	⁃	High Concurrency / High Speed Processing
	⁃	XA -> eXtended Architecture -> distributed transactions (use just if absolutely necessary)
	⁃	How to choose the right transaction management strategy for your project?
	⁃	Logging
	⁃	technical text based output for debugging and detecting problems
	⁃	detail can be configured at runtime
	⁃	not easily understandable for users
	⁃	TECH:
	⁃	avoid string concat, expensive operations, too much output, stdout or stderr
	⁃	provide contextual information (userID, sessionID, threadID, etc.), use tools
	⁃	limit categories
	⁃	clear rules when to use the categories
	⁃	Auditing
	⁃	domain specific, fine grained, structured output tracing user activity
	⁃	requirements specified in policies
	⁃	used by some end user groups (internal revision)
	⁃	frequently coupled with long term retention requirements (10+ years)
	⁃	Security
	⁃	Identity Management
	⁃	how to handle user related data —> databse, custom app, LDAP (lightweight directory access protocol), managing users (complex)
	⁃	Entities - correspond to - Identities - consist of - Attributes / Identifiers
	⁃	Authentication
	⁃	Username/Password (easiest)
	⁃	Certificate based (client authentication, more complex-> high security)
	⁃	Token based / Single Sign on (SSO)
	⁃	Smart Card, Biometric (needs client support)
	⁃	Authorization
	⁃	Role based access control (RBAC, frequently used for resource based systems -> Windows, users get roles with defined permissions)
	⁃	Permission based (simple action based, each action can be done with specific permissions)
	⁃	Access control lists (ACL, fine grained control on instance level, each user gets specific rights on specific objects)
	⁃	Rule based (for complitaced frequently changing stuff)
	⁃	
	⁃	Permission/Role based (simple security requirements, easy to govern, well supported by tech, min performance needed)
	⁃	Declarative Security -> provided out of the box, forces to use specific mechanisms
	⁃	Error Handling
	⁃	User error VS program error
	⁃	program flow VS Exception
	⁃	Checked Exception (muss gefangen werden, programmierer kann nix dafür -> FilenotfoundEx)
	⁃	Unchecked Exception (muss nicht gefangen werden -> RuntimeEx, deutet auf fehler hin muss aber keiner sein (numberformatEx))
	⁃	Error
	⁃	Handling low level Exceptions
	⁃	HINTS
	⁃	Do either log or throw
	⁃	catch or throw
	⁃	always pass the causing exception (wrapping)
	⁃	do NOT catch and ignore
	⁃	do NOT throw within finally (swallows all other exceptions)
	⁃	HANDLE ONLY IF YOU CAN DO SOMETIHNG AGAINST IT
	⁃	Internationalization
	⁃	preparation of a product for use in the global market (done once —> preparation of the product for the Localization)
	⁃	Locailization
	⁃	Performing specific adaptions necessary to launch a product in a specific locale (e.g. changing pictures, language, format (utf8), text orientation, currency, number format etc)

	⁃	6) Build for ten years and more
	⁃	Key factor is CHANGE:
	⁃	Reuse
	⁃	Extendability
	⁃	Feature Changes
	⁃	Scaleability
	⁃	Maintainability
	⁃	Testing for regressions
	⁃	Decomposition of a system into indepentent parts
	⁃	Recomposition of parts into a coherent system (context aware!!)
	⁃	Component VS Service (after Fowler)
	⁃	main difference -> component is just used locally without change (no source code change, just behaviour) and a service is used remotely via some remote interfaces
	⁃	Interfacing / Integration
	⁃	key design decisions
	⁃	service (pull)
	⁃	message (push) 
	⁃	data coupling
	⁃	runtime VS built time
	⁃	sync (req-resp) VS async (callback)
	⁃	ID VS natural key
	⁃	Design decisions for different stuff
	⁃	message interface
	⁃	sync vs async, payload, events, event types
	⁃	data coupling
	⁃	separation of schema, read via views, write via procedures
	⁃	Layered Software Design / API Design
	⁃	Reasons
	⁃	Seperation of Concerns
	⁃	Abstraction
	⁃	Testability
	⁃	Error Handling
	⁃	Transaction Mgmt
	⁃	Reuse
	⁃	Cut into layers
	⁃	UI from Logic
	⁃	Model from Logic
	⁃	data access from logic (via common interface, e.g. REST)
	⁃	connectors from logic (via common interface, e.g. REST)
	⁃	Forms of modularization (wichtiges Bild, seite 19)
	⁃	Build Time (Maven)
	⁃	Runtime (single VM) (OSGI)
	⁃	Runtime (multi VM)
	⁃	DEPENDENCY INJECTION (seite 22)
	⁃	DI is a pattern, where the gluing of objects is separated from the implementation
	⁃	There is a central definition and container that creates and binds objects together
	⁃	lazy creation of objects possible (on demand creation)
	⁃	supports code reuise and independently testing classes
	⁃	supports different bindings for different environments
	⁃	Interface Injection, Setter Injection, Constructor Injection
	⁃	Abhängigkeiten werden zur laufzeit von einer zentralen instanz erstellt und gebunden
	⁃	Aspect oriented programming (AOP)
	⁃	Event based architecture
	⁃	Eventing VS Batch

	⁃	7) From prototype to product
	⁃	waterfall: plan, specify, design, build, test, deploy (no incentive (ansporn) to think about operations before testing)
	⁃	agile: potentially shippable code every day

	⁃	Configuration Management (CM)
	⁃	Configuration management is a management process for establishing and maintaining consistency of a products
				performance, its functional and physical attributes, with its requirements, design and operational information, throughout its life.
	⁃	build config
	⁃	state of source code
	⁃	dependencies
	⁃	requirements
	⁃	product config
	⁃	application server config
	⁃	database config
	⁃	os config
	⁃	system config
	⁃	application level
	⁃	often in db and /
	⁃	as few places as possible
	⁃	make it easy to view/change
	⁃	clear distinction between environment and product conf
	⁃	system level
	⁃	user.timezone, user.language
	⁃	automate!!
	⁃	clustering (menge von objekten mit ähnlichen eigenschaften)
	⁃	(Session replication is a mechanism used to replicate the data stored in a session across different instances)
	⁃	full session replication
	⁃	partial session rep
	⁃	database level clustering
	⁃	load balancing
	⁃	sticky session 
	⁃	round robin
	⁃	active/passive
	⁃	hard- VS software
	⁃	load and fault tolerance tradeoff	

	⁃	Focus: Master Node Election
	⁃	Performance
	⁃	Test vs Development
	⁃	Measure
	⁃	Profiling
	⁃	Tracing
	⁃	to aggregate or average call performance
	⁃	bad for runtime behaviour (affects sys performance)
	⁃	Sampling
	⁃	to trace down performance issues to a specific call
	⁃	Manual
	⁃	good to see call durations
	⁃	good for runtime behaviour
	⁃	good for adaptive measuring
	⁃	bad if really done manually
	⁃	bad for measuring everything
	⁃	Monitoring
	⁃	system states
	⁃	system resources
	⁃	java behaviour
	⁃	infrastructure state
	⁃	Application level
	⁃	ui reachable?
	⁃	ui reach backend?
	⁃	backend reach db?
	⁃	backend reach other system?

	⁃	8) Software Architectures for Collective Intelligence 1
	⁃	Collective Intelligence
	⁃	Group intelligence that emerges from COLLABORATION, COLLECTIVE ACTION, and COMPETITION of many individuals.
	⁃	Requires to stimulate, aggregate, leverage and distribute user contributions through an ICT system as mediator.
	⁃	Our Take:
	⁃	1) achieved by hybrid systems in which humans and computers interoperate
	⁃	2) potential for highly effective collection and distribution of hard-to-access knowledge
	⁃	3) used for Crowdsourcing, Social Web/Media, Social/Human Computing
	⁃	CI systems
	⁃	users as contributors
	⁃	user participation
	⁃	trust the community
	⁃	folksonomies (free classification of information (tagging))
	⁃	Dispersion (file sharing)
	⁃	mass participation
	⁃	Systems -> Facebook, Flickr, Twitter, Youtube, Slideshare…
	⁃	Key Stakeholders
	⁃	Users
	⁃	awareness of new stuff
	⁃	building upon content and knowledge of others
	⁃	contribution
	⁃	effective buttom-up communication
	⁃	Platform Providers
	⁃	network effect
	⁃	data collection extremely valuable
	⁃	Systems:
	⁃	Social network services (Facebook, Twitter..)
	⁃	Crowdsourcing (Innocentive, TopCoder, Amazon Mechanical Trunk)
	⁃	Media / Content Sharing (Youtube, flickr)
	⁃	Knowledge Creationg (Wikipedia, Yelp, ..)
	⁃	Main Directions
	⁃	Crowds around a certain topic
	⁃	Use crowds from existing CI systems within new contexts
	⁃	Challenges
	⁃	Designing
	⁃	Perpetual beta
	⁃	Getting an active community of contributors
	⁃	Scaling
	⁃	CI Design Patterns
	⁃	Tagging
	⁃	Rating
	⁃	Comments
	⁃	Hashtags
	⁃	Recommendations
	⁃	Generated Lists
	⁃	Follow / Subscribe
	⁃	Activity Indicator
	⁃	User generated Collections
	⁃	CI Systems Helping 
	⁃	Issue Tracking
	⁃	Knowledge Management
	⁃	Programming Q&A
	⁃	….
	⁃	Success Factors
	⁃	right system type
	⁃	design patterns
	⁃	easy to contribute
	⁃	make users aware about the activites of the other users
	⁃	Risk Factors
	⁃	not well integrated in user workflow routines
	⁃	other CI systems
	⁃	security and privacy of user data
	⁃	CI Research
	⁃	reorganize work in new ways
	⁃	hybrid human-computer systems
	⁃	build upon work already done
	⁃	new software architectures
	⁃	knowledge mgmt
	⁃	process improvement

	⁃	9) Software Architectures for Collective Intelligence 2
	⁃	Web Application Frameworks (all MVC and Cross-platform)
	⁃	Ruby on Rails
	⁃	fast & agile
	⁃	framework
	⁃	Django
	⁃	fast & agile
	⁃	framework
	⁃	Java EE
	⁃	focus on: scalability and enterprise IT integration
	⁃	platform
	⁃	DIFF - PROS AND CONS
	⁃	Ruby VS JavaEE (p.11)
	⁃	Ruby: 
	⁃	easy & quick, fast dev, short trial & error cycles, less boilerplate code
	⁃	harder customization, scaling, slower execution of ruby
	⁃	JavaEE
	⁃	tools in -> performance, stability, maintainability; ,  scaling, long term support, libs more flexible and powerfull
	⁃	complex setup/configuration, slow response to industry changes, coding and maintenance overhead
	⁃	Amazon Mechanical Turk (MTurk)
	⁃	Crowdsourcing online marketplace for workforce-on-demand
	⁃	enables companies and individuals to coordinate the use of human intelligence
	⁃	requesters put tasks online and workers can voluntariliy choose one
	⁃	project -> break into tasks -> publish HITs (Human Intelligence Task) -> worker accept assignment -> worker submits assignment -> approve or reject solution -> completed

	⁃	Mechanical Turk Masters
	⁃	workers who have demonstrated consistent accuracy on specific types of HITs
	⁃	CI - Systems
	⁃	Centralized CI
	⁃	acts as „one“ platform and is operated by a single provider
	⁃	central administration
	⁃	single data system
	⁃	most CI systems are centralized
	⁃	Decentralized / Federated CI
	⁃	distributed across mulitple providers
	⁃	system consists of independent CI system instances (nodes) which are able to communicate with each other
	⁃	Examples: GNU Social, Diaspora
	⁃	Data Formats: JSON
	⁃	Protocols: 
	⁃	JSON Activity Stream
	⁃	PubSubHubbub (server-to-server, publish / subscribe, real-time updates via pushed HTTP notifications, publishers, subscribers and hubs)
	⁃	Salomon (msg exchange protocol, enables decentralized commenting/annotating)
	⁃	Webfinger (discovering of entities via URI (Link based resource descriptor (LRRD) , returns JSON doc to valid query)
	⁃	OStatus (specification for distributed status updates or microblogging, lets people on different social networks follow each other)

	⁃	Communication: OStatus

Bringing it all together: Following a feed in a microblog 
Bob wants to subscribe to Alice’s public feed and Alice should be informed about it. 
	1.	Bob discovers the LRDD of Alice using Webfinger. 
	2.	Bob subscribes to Alice’s public feed using PubSubHubbub. 
	3.	Bob sends an ActivityStream Atom Entry to Alice using the Salomon protocol to notify her about the event.

	⁃	Tradeoff Centralized vs. Decentralized (p. 31)
	⁃	Centralized
	⁃	+) constant quality of service, single point of access, more resources, single organization
	⁃	-) sinlge point of failure, likely to suffer from censorship and infiltration by government, often closed source co
	⁃	Decentralized
	⁃	+) multiple points of access, robust, often open source sw, easier on non-profit basis
	⁃	-) QoS, security, maintenance dependant on individual node, less effective information exchange, user data saved on indiv. node

	⁃	KEY TAKEAWAYS FROM THE CI PART (IMPORTANT !!!) —> HINTS

	•	What are CI Systems?  – Main constructive directions, challenges, success/risk factors.
	•	CI design patterns.
	•	Centralized/decentralized CI systems.  – Characteristics and trade-offs.
	•	Communication in decentralized CI systems.  – OStatus.  – Formats and protocols. 
	•	Amazon Mechanical Turk and its concepts. 
	•	Ruby on Rails VS Java EE.  
	⁃	10) Anti Patterns
	⁃	Pattern —> A general reusable solution to a commonly occuring problem within a given context.
	⁃	common vocabulary
	⁃	patterns capture expert knowledge and design tradeoffs
	⁃	facilitates non-functional requirements (reusabilty, adaptability, extendability, …)
	⁃	minimizes development time and costs
	⁃	improves documentation
	⁃	Classifications
	⁃	Architectural
	⁃	structure of systems
	⁃	subsystems, dependencies, communication
	⁃	Design
	⁃	describes the structure and relations at the level of classes
	⁃	Types: Creational (initializing, configuring classes), Structural (decoupling interface and implementation), Behavioral (dynamic interaction)
	⁃	Idioms
	⁃	focus on low-level details
	⁃	programming language specific (for special problems that just a specifc language has, e.g. type safety in C because just in C this idiom is needed)
	⁃	Protopatterns
	⁃	particular case
	⁃	a new, understandable solution to be used in larger scale
	⁃	Anti Pattern —> solution that generates negative consequences
	⁃	pattern becomes an anti pattern if it causes more problems than it solves
	⁃	Key Concepts
	⁃	Root Causes
	⁃	mistakes resulting in failed projects
	⁃	Primal forces
	⁃	Software design-level models
	⁃	Software design-level model
	⁃	seperate concerns based upon the scale of software solution
	⁃	ensure appropriate solutions are applied at their correct level
	⁃	micro-component levels
	⁃	dev of sw-components that solve recurring problems
	⁃	macro-component levels
	⁃	organization and dev of application frameworks
	⁃	design issues
	⁃	object & classes (dev of reusable code)
	⁃	micro architectures (mgmt of patterns combining serveral classes)
	⁃	frameworks (dev of pattern involving micro architectures)
	⁃	application level (app dev meeting user requirment)
	⁃	system level (communication and coordination accross apps)
	⁃	enterprise level (communication in organization, distributed hard and software systems)
	⁃	global / industry level (cross organizational communication, information sharing)
	⁃	How does it happen
	⁃	to little knowledge
	⁃	wrong context of a pattern
	⁃	not sufficient knowledge of a problem
	⁃	Characteristics
	⁃	General Form
	⁃	Primary Cause
	⁃	Symptoms
	⁃	Consequences
	⁃	Refactored Solution
	⁃	Key Concepts:
	⁃	Causes:
	⁃	Hasty Decisions
	⁃	Impassivity
	⁃	Sloth
	⁃	Ignorance
	⁃	Pride
	⁃	Forces:
	⁃	SW design is about making choices
	⁃	context needs to be clarified
	⁃	Vertical forces (domain-specific forces)
	⁃	Hroizontal forces (influence choices across several software modules)
	⁃	TODO Software Design-Level-Model
	⁃	Types:
	⁃	Software Development Anti Patterns
	⁃	Software Architectur AP
	⁃	Sofware Project Management AP
	⁃	Sofware Project Management Anti Pattern Examples:
	⁃	Analysis Paralysis (too much analysing of the problem)
	⁃	Viewgraph Engineering (too much graphs, views, models)
	⁃	Death by Planning
	⁃	Smoke and Mirrors (Mgmt makes promises unable for dev team)
	⁃	Project Mismanagement (design too difficult, not evalutae design defects, insuffient tests and risk mgmt, lack of common understanding)
	⁃	Software Dev Anti Patterns:
	⁃	The Blob (use of object-oriented languages but the archtiecture is procedural —> single class with high complexity)
	⁃	Lava flow (undocumented complex code, lot of commented out code with no explanation, because of wrong developers
	lack of configuration mgmt, unclear goals)
	⁃	Golden Hammer (use convenient tool for problems that do not fit the tool)
	⁃	Spaghetti Code (almost no software structure —> inexperience in OO, lack of reviews)
	⁃	Copy Paste Programming
	⁃	Prevention
	⁃	Think
	⁃	Develop a plan of action
	⁃	Act

	⁃	11) FOSS (Free / Open Source Software)
	⁃	Big benefit of OSS if you hit a bug in a FOSS framework
	⁃	you dont need workarounds but can fix bugs directly in the OSS libs
	⁃	Different licenses (MIT, Apache, Creative Commons, ALWAYS add a license)
	⁃	Copyright
	⁃	subjektive und absolute recht auf geistiges eigentum
	⁃	Trademark
	⁃	name must be unique (in your field)
	⁃	Marke die in einem verzeichnis eingetragen ist
	⁃	Monetise OSS
	⁃	add commercial value
	⁃	professional training
	⁃	embedd into hardware (android)
	⁃	service contracts
	⁃	consulting
	⁃	Apache Software Foundation (ASF)
	⁃	Founding Principles of Apache
	⁃	„The Foundation exists to serve the development community“ Bill Stoddard
	⁃	„Let developers focus on what they do best: Code. The foundation exists to do the rest“ Justin Ehrenkranz
	⁃	Not-for-profit Organisation
	⁃	Volunteer Organisation
	⁃	(Community over Code, Community for Code)
	⁃	Apache License v 2.0 (ALv2)
	⁃	Liberal open source software license
	⁃	business friendly
	⁃	requires attribution
	⁃	includes patent grant
	⁃	can be SUB-LICENSED (add your own code in any license)
	⁃	no RE-LICENSING allowed (would allow to change the license of all code)
	⁃	Apache Structure
	⁃	Board of directors
	⁃	ASF Members
	⁃	Project Mgmt Commitee (PMC) Members
	⁃	Comitters
	⁃	Contributors
	⁃	Incubator
	⁃	Public Relations, …

	⁃	12) FOSS - Free Open Source Software and the Eclipse Ecosystem
	⁃	Copyleft ist eine Klausel in urheberrechtlichen Nutzungslizenzen, die festschreibt, dass Bearbeitungen des Werks nur dann erlaubt sind, wenn alle Änderungen ausschließlich unter den identischen oder im Wesentlichen gleichen Lizenzbedingungen weitergegeben werden

	⁃	What is FOSS (def. by Bruce Perens)
	⁃	Free Redistribution 
	⁃	(license shall not restrict from selling or giving away)
	⁃	Source Code 
	⁃	(program must include source code, must allow distribution in source code as well as compiled form, no charge (money))
	⁃	Derive Works 
	⁃	(license must allow modifications and derived works)
	⁃	Integrity of the Authors Source Code
	⁃	 (The license my require derived works to carry a different name or version)
	⁃	No Discrimination against Persons or Groups (license)
	⁃	No Discrimination against Fields of Endeavor
	⁃	 (license must not restrict anyone from making use of the program in a specific field of endeavor)
	⁃	Distribution of License	
	⁃	 (rights aplly to all to whom the program is redistributed without the need for execution of an additional license)
	⁃	License must not be specific to a Product 
	⁃	(The rights attached to the program must not depend on the programs being part of a particular sw distirbution)
	⁃	License must not restrict other Software
	⁃	(license must not place restrictions on other software that is distributed along)
	⁃	License must be Technology-Neutral
	⁃	Organisations
	⁃	Free Software Foundation (FSF) - Free SW
	⁃	Open Source Initiative (OSI) - Open Source SW
	⁃	Cathedral and the Bazaar
	⁃	Cathedral
	⁃	source code is available with each software release but between restricted to an exlusive sw developer group (e.g Emacs, GCC)
	⁃	Bazaar
	⁃	code is developed over the internet in view of the public (always open, e.g. Linux)
	⁃	FOSS Business Models
	⁃	Sell services
	⁃	Sell Extensions / Components / Features
	⁃	Forking and porting-back with delay
	⁃	Forking and financing maintenance
	⁃	Dual license models (Copyleft and commercial friendly license combined, e.g. MySql)
	⁃	Publicity for other software or services
	⁃	Personal publicity of the author and career opportunities
	⁃	Sponsorship and donations
	⁃	Academic research (e.g. Kerberos, findbugs, …)
	⁃	FOSS Communities
	⁃	Large project usually managed by a legal entity —> e.g. Eclipse Foundation
	⁃	Communication (normally completely open —> Website, Mail, Blogs, Conferences …)
	⁃	Infrastructure (usually forge or sponsored
	⁃	FOSS Forges
	⁃	Forges provide the most common infrastructure for the projects (e.g. Java.Net, Github, Bitbucket, Sourceforge)
	⁃	Project Mgmt Commitee (PMC)
	⁃	a PMC has one or more PMC leads and zero or more PMC members
	⁃	together the PMC provides oversight and ovearll leadership for the projects that fall under their top-level project
	⁃	Eclipse Public License (EPL)
	⁃	Weak-copyleft business friendly free license
	⁃	According to article 1(b) of the EPL, additions to the original work may be licensed independently, including under a commercial license, provided such additions are "separate modules of software" and do not constitute a derivative work. Changes and additions which do constitute a derivative work must be licensed under the same terms and conditions of the EPL, which includes the requirement to make source code available. 
	⁃	Eclipse Mylyn
	⁃	Task-Focused Interface for Eclipse
	⁃	Integrating rich and offline editing for repositories such as Bugzille, Trac and JIRA
	⁃	TapiJl 
	⁃	Integrated Internationalization Environment
	⁃	Tooling for agile and process integrated Java Internationalization
	⁃	Set of Eclipse-Plugins to aid developers and translators in working with internationalized SW