WebSphere Software Presentation Template

thingyvirginiaInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 4 χρόνια και 8 μήνες)

296 εμφανίσεις

Best Practices using Open Source Software in
Commercial Products

Bill Stoddard

ApacheCon Europe 2007

2

Agenda

What is Open Source?


Legal


Community


Service Stream Maintenance


Final Thoughts


ApacheCon Europe 2007

3

What is Open Source?

License


Few restrictions on redistribution and use


OSI Certified:
http://opensource.org/docs/certification_mark.php


Community


Community is build around code and is more important that code


Values transparency, free exchange of ideas & individual innovation


Shared goal(s)


Geographically diverse


Collaborative Development Methodology


Shared information space (revision control system)


Shared communication (mailing lists, wiki)


Governing processes (conflict resolution, legal vetting, admitting new ‘trusted’
members, organizational continuity that outlives individual community members)


ApacheCon Europe 2007

4

Questions to ask


How will the OSS be used?


ISV, IT vendor, reseller


create new business opportunities


Accelerate open standards adoption


Consulting & Services


Subscription/Support



Will you redistribute the OSS?



Will you package OSS with proprietary extensions?



How will you support the OSS?



Will you become involved in the developer community?

ApacheCon Europe 2007

5

Agenda

What is Open Source?


Legal


Community


Service Stream Maintenance


Final Thoughts


ApacheCon Europe 2007

6

Legal

Caveat



I am not a lawyer.



This is not legal advice.



This information is intended to give you context in
conversations with your legal team




ApacheCon Europe 2007

7

Legal

Two questions



Q1: Does the license allow you to do what you want?




Q2: Are you certain?




ApacheCon Europe 2007

8

Legal

But what you really need is….

ApacheCon Europe 2007

9

Legal


Due Diligence



Method for investigating source code provenance


Hard work

ApacheCon Europe 2007

10

Legal

Due Diligence Step 1


Know your supplier



Apache Software Foundation


Codehaus


Sourceforge


Usenet posting



Look for code contribution guidelines


Contributor License Agreements (CLAs)


Click
-
thru JIRA submissions

ApacheCon Europe 2007

11

Legal

Due Diligence Step 1 cont… (snip from ASF iCLA)

You accept and agree to the following terms and conditions for Your
present and future Contributions submitted to the Foundation….


1.
Definitions. "You"

(or "Your") shall mean the copyright owner or legal entity
authorized by the copyright owner that is making this Agreement with the
Foundation. For legal entities, the entity making a Contribution and all other
entities that control, are controlled by, or are under common control with that
entity are considered to be a single Contributor. For the purposes of this
definition, "control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or otherwise, or
(ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii)
beneficial ownership of such entity.
"Contribution"

shall mean any original
work of authorship, including any modifications or additions to an existing
work, that is intentionally submitted by You to the Foundation for inclusion in,
or documentation of, any of the products owned or managed by the
Foundation (the "Work"). For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent to the
Foundation or its representatives, including but not limited to communication
on electronic mailing lists, source code control systems, and issue tracking
systems that are managed by, or on behalf of, the Foundation for the purpose
of discussing and improving the Work, but excluding communication that is
conspicuously marked or otherwise designated in writing by You as "Not a
Contribution."

2.
Grant of Copyright License.

Subject to the terms and conditions of this
Agreement, You hereby grant to the Foundation and to recipients of software
distributed by the Foundation a perpetual, worldwide, non
-
exclusive, no
-
charge, royalty
-
free, irrevocable copyright license to reproduce, prepare
derivative works of, publicly display, publicly perform, sublicense, and
distribute Your Contributions and such derivative works.

3.
Grant of Patent License
.

Subject to the terms and conditions of this
Agreement, You hereby grant to the Foundation and to recipients of software
distributed by the Foundation a perpetual, worldwide, non
-
exclusive, no
-
charge, royalty
-
free, irrevocable (except as stated in this section) patent
license to make, have made, use, offer to sell, sell, import, and otherwise
transfer the Work, where such license applies only to those patent claims
licensable by You that are necessarily infringed by Your Contribution(s) alone
or by combination of Your Contribution(s) with the Work to which such
Contribution(s) was submitted. If any entity institutes patent litigation against
You or any other entity (including a cross
-
claim or counterclaim in a lawsuit)
alleging that your Contribution, or the Work to which you have contributed,
constitutes direct or contributory patent infringement, then any patent licenses
granted to that entity under this Agreement for that Contribution or Work shall
terminate as of the date such litigation is filed.



4.
You represent that you are legally entitled to grant the above license.

If your
employer(s) has rights to intellectual property that you create that includes your Contributions,
you represent that you have received permission to make Contributions on behalf of that
employer, that your employer has waived such rights for your Contributions to the Foundation,
or that your employer has executed a separate Corporate CLA with the Foundation.


5. You represent that each of
Your Contributions is Your original creation

(see section
7 for submissions on behalf of others). You represent that Your Contribution submissions
include complete details of any third
-
party license or other restriction (including, but not limited
to, related patents and trademarks) of which you are personally aware and which are
associated with any part of Your Contributions.


6. You are not expected to provide support for Your Contributions, except to the extent You
desire to provide support. You may provide support for free, for a fee, or not at all. Unless
required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS"
BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied,
including, without limitation, any warranties or conditions of TITLE, NON
-

INFRINGEMENT,
MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.


7. Should You wish to submit work that is not Your original creation, You may submit it to the
Foundation separately from any Contribution, identifying the complete details of its source and
of any license or other restriction (including, but not limited to, related patents, trademarks, and
license agreements) of which you are personally aware, and conspicuously marking the work as
"Submitted on behalf of a third
-
party: [named here]".


8. You agree to notify the Foundation of any facts or circumstances of which you become aware
that would make these representations inaccurate in any respect.



Please sign:

__________________________________ Date: ________________



ApacheCon Europe 2007

12

Legal

Due Diligence Step 2


Provenance



Where did the code come from, original author, primary contributors


Has the license changed?


How did the code come to arrive in the package your investigating?



Resources…


Browser interface to SVN/CVS version control repositories


Dev mailing list archives



ApacheCon Europe 2007

13

Legal

Due Diligence Step 3


Keyword scan



Looking for anything ‘interesting’ that suggests code provenance


Copyrights, license, email addresses, “author”, “SCO”…


Need good way to filter out uninteresting keyword hits (“apache” in an ASF
project)



Define process for investigating ‘interesting’ hits


ApacheCon Europe 2007

14

Legal

Due Diligence Step 4


Records



Assemble Due Diligence package



Keep it in a revision control system



ApacheCon Europe 2007

15

Legal

Give Credit where credit is due


Acknowledge Creators



In ‘usual place’ (notices or license file, during install, etc)



Documentation



ApacheCon Europe 2007

16

Legal

Things to make you go “Hummmm…..”


How you package OSS in your product could have
legal consequences



Is code segregated or intermingled with your proprietary code?



Go figure…



ApacheCon Europe 2007

17

Legal

Conclusion

The “Chewbacca” Defense

http://en.wikipedia.org/wiki/Chewbacca_Defense

“If Chewbacca lives on Endor, you must acquit”

ApacheCon Europe 2007

18

Agenda

What is Open Source?


Legal


Community


Service Stream Maintenance


Final Thoughts


ApacheCon Europe 2007

19

Community

User or Developer?

Two communities to consider:



User



Developer

ApacheCon Europe 2007

20

Community

Modeling of a Community



H
a

U + D * (I / E)



where:


H

= Community health


U

= # users


D

= # developers


I

= Developer Intrinsic motivation (end user)


E

= Developer Extrinsic motivation (not an end user, ‘professional’ developer?)


ApacheCon Europe 2007

21

Community



Reasons for getting involved in the dev community




Influence the direction of the community



Share user experience, communicate requirements



Contribute bug fixes



Innovate



Drive adoption of open standards



Get stuff done

ApacheCon Europe 2007

22

Community

Stuff you should know…

Developer Community


Volunteers


Fun & recognition


Use OSS in their job


Training & consulting



Academics



“Professional” Open Source Developers


ApacheCon Europe 2007

23

Community

OSS Developer Community 101: Key Concept

Brutal Meritocracy



Open source projects are governed by those with merit



Earn merit by contributing, prove your technical and social cluefullness



Early missteps can compromise your effectiveness in the community


ApacheCon Europe 2007

24

Community

OSS Developer Community 101: Key Concept
(cont.)


Brutal Meritocracy



Your corporate affiliation don’t matter



Your schedules don’t matter



You have no rights in the community…

Until you earn those rights, by demonstrating cluefullness.

ApacheCon Europe 2007

25

Community

First Step … Lurk, Listen and Learn

Organization


Despot, peer or consortium?



Thought leaders



How are releases made, who does the work


Operational



Conflict resolution


leader fiat, discussion, bighorn sheep




How to submit patches, bug reports,


Community intrigue


identify frictions in the community

ApacheCon Europe 2007

26

Community

Next Steps…

Research questions before you ask


Start Small don’t come on too strong


Scratch a community itch


Respect developers time


Recognize that everyone has an ego


Thoughtful technical arguments presented well earn respect

Demonstrate Enlightened Self Interest

Maybe you will be invited to become a committer

ApacheCon Europe 2007

27

Community

Special Problems of “Professional” OSS development

Companies want to:


Define release content



Assign work



Set schedules


Trade innovation for predictability


Reduce intrinsic motivation, stifles innovation


Conservative


reluctant to throw away code, try something new


ApacheCon Europe 2007

28

Community

What makes a community successful?

Intrinsic Motivation:


“Your own natural desire to do things well” *


“People work much harder at things they actually want to do” *


Extrinsic Motivation:


Not as strong as intrinsic motivation


Puts food on the table


Can be coercive


Yields somewhat more predictable results





*
Joel Spolsky

ApacheCon Europe 2007

29

Community

How to fail miserably



Short
-
sited & Self
-
serving



Ignore discussions not directly related to your interests



Ignore the user community



Don’t do your share of the ‘dirty work’



Be sneaky



Back room decisions



Spring significant amounts of new code on the community with little or no prior
discussion


Place corporate agenda ahead of community


Project your problems onto the open source community



ApacheCon Europe 2007

30

Community

Review: Guiding Principles

The Brutal Meritocracy


Open source projects are governed by those with merit


Earn merit by contributing


Participate in the community as an individual, only representing YOURSELF


Overtly corporate ‘presence’ unwelcome


The most effective communities are brutally effective at enforcing their standards


Don’t be selfish with your time, stay engaged in the community


Assist users


Fix bugs


Stay on top of technical discussions, even if they are not directly relevant to your interests


Scratch community itches (don’t be insular and self centered)


Demonstrate enlightened self interest



Spend time learning community organization and operational processes


Too many to list


Be transparent


no backroom decisions, no surprise codedrops


Respect developer’s time commitments


Readings

http://www.catb.org/~esr/writings/cathedral
-
bazaar/cathedral
-
bazaar/



ApacheCon Europe 2007

31

Agenda

What is Open Source?


Legal


Community


Service Stream Maintenance


Final Thoughts


ApacheCon Europe 2007

32

Service Stream Maintenance

Infrastructure



Setup internal source code revision control system


Manage internal development like an open source project


Manage Multiple defect streams



Open Source user/developer community


Internal test team


Your customers


ApacheCon Europe 2007

33

Service Stream Maintenance

General principles



Work defects in the open source community


peer review
leverages the collective wisdom of the community



Roll peer
-
reviewed fixes from the OS community into your service
stream



Subscribe to the source code commit mailing list… watch every
single patch that goes into the source and assess whether your
customers would likely need the fix. Fix problems in your service
stream before your customers ever see them



Don’t fork the code base w/o understanding the consequences


ApacheCon Europe 2007

34

Service Stream Maintenance

Security/Integrity defects



This is where being a project committer can be very worthwhile


Subscribe to the project’s private mailing list to gain some lead time to fix
problems in your product


Extension Points



Sometimes it is possible to get extension points into the open source code
that are generally useful but can be leveraged by you for proprietary
extensions (or stuff the community simply is not interested in)





ApacheCon Europe 2007

35

Agenda

What is Open Source?


Legal


Community


Service Stream Maintenance


Final Thoughts


ApacheCon Europe 2007

36

Final Thoughts

Corporate involvement



Fact


What (if anything) can an OS community do to ease the friction?



Radical Simplicity


Pre corporate OSS communities were severely resource constrained.


Much less likely to do things 'because we can'.


End result was simplest solution to problems


Almost never over
-
engineered, over optimized


Keep it simple, keep barriers to entry low..