fitz / pcloadletter Goto Github PK

A common criticism that I hear when discussing open source with people who
are not involved in the milieu is that open source does not innovate. The
canonical examples cited are of course OpenOffice ("They're just cloning
That Other Productivity Suite!") and the Gnome/KDE desktop environments
("Companies did and paid for the hard UI research work, open source just
takes that hard work and implements with no additional thought!"). In other
words, they see open source as a group of "(code) monkey see, (code) monkey
do" people, that will always be playing catch-up with closed source innovators.

A further comment is that when a particular piece of open source software
does present innovative features (I think the case in point was the Linux
kernel), it is usually due to a company pledging resources towards
implementing that feature for their own specific business needs, and not to
the mythical grassroots bazaar of hackers in their free time.

Do you think that open source communities on the whole innovates less than
the closed source counterparts? Do you have examples of instances where
open source communities were the source of particular innovations that then
propagated into the proprietary world? Can open source communities be
innovative at the "hacker in her free time" level, without the drive of
companies? And, while "innovation" in general is obviously important for a
company, should it have the same (or any) importance for open source projects?

Hi!

Question for Ben: regarding your article "Version control and the 80%" (
http://blog.red-bean.com/sussman/?p=79 ), you said:

<<<<<<<<<<<<<<<
The 80% folks make up the bulk of the software development industry... They
use whatever tools Microsoft hands down to them — usally VS.NET if they’re
doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java
development. They’ve never used Linux, and aren’t very interested in it
anyway...

Most of the software industry is made up of 80% programmers. Yes, most of
the world is small Windows development shops, or small firms hiring
internal programmers.
>>>>>>>>>>>>>>>

So my question is: are you sure most developers are working on Windows? Not
according to the article which I referenced in http://xrl.us/ben9h :

"Linux is becoming the development platform of choice; for example, it is
expected that more developers will be developing on Linux than Windows by
2004;"

Do you agree with this, and if so - how does it reflect on your post?

Regards,

       Shlomi Fish

Just curious if there are any plans to do additional episodes or if this is
pretty much done 

I've been thinking about this for awhile and have recently talked to Karl
Fogel (of SVN/Producing OSS fame) about the idea - which is how I heard
about this podcast. 

I think it would be really useful to have a support group/ discussion
forum/mailing list for Leaders of open source projects to discuss various
non-code issues with each other. A lot of the topics from Karl's book -
like how to deal with finding a violation of your license or how to recruit
more/better developers to your project or how to market your project to the
world or even issues revolving around commercialization in your community

What steps will reproduce the problem?
1. Don't have iTunes.
2. Click on "subscribe w/iTunes
3. Be thwarted.

;-)

Can we get a raw RSS feed link please?

How to commercial organizations relate to open source?  How do you make money?  
How do you 
give back?  Garrett Rooney had a good blog entry on this, a while back, which 
I'm sure you both 
read at the time; what are your thoughts? (Guest speaker?)

Perhaps you could devote a few episodes to specific social issues in open
source development, and have examples of the *bad* way things have been
done (boo!) and then the *good* way someone else did things (yay!).  You
could even have some boos and cheers for sound effects.  That said, I think
you could use some bass guitar in your intro music--let me know if I can help.

I have been using subversion for over 2 years not just as source control
for code but also in certain apps of mine where i embed the subversion
repository to store versions of different data sets. Due to the large size
of data and also the large time frame over which i have maintained
different version i now have the problem of repository bloat. My current
subversion repository is close to 15 GB and growing. The strange thing
about the SVN APIs is that there is no way to delete the content i don't
need. The SVN delete provided via APIs is only logical i.e. deleting a node
just delinks it from the main tree but does not delete the versions
physically so they still continue to consume disk space.

So here is my question, was the physical delete feature not provided by
design or was it skipped due to lack of insight? could you talk a little
about it.

Question to Ben:

I've tried to post a comment to your blog, but it bounced, so I posted it
on my technical journal here:

http://community.livejournal.com/shlomif_tech/4589.html

I'd be happy if you can respond to it in one of the upcoming podcasts.

Regards,

       Shlomi Fish

Fancy talking about 1.5 ?

http://subversion.tigris.org/svn_1.5_releasenotes.html

Can you talk a touch more about the history of Subversion? What is Tigris
all about? From an outsider, Subversion got a lot of hype early on, but it
seemed quiet for a long time and then hit a tipping point. How did you
reach that tipping point? Was self-hosting on SVN the big point? Where do
you see SVN going in the future?

I would like to talk about best practices for developing/managing
documentation efforts for an open source project. Many people seem to
believe that a wiki is the end-all-be-all best/only solution. I think that
a wiki can have its place, but I would also like to hear issues such as
including documentation in-line with the code and producing hard copy docs. 

The big issue I'd like to hear talked about is the best way to produce it -
from the process/people to the tool chain and production. I think it would
be best to be able to keep documentation in DocBook format inside of the
svn repository with the rest of the code, but I can't seem to find and high
quality and free tools to work with it which seems to raise the barrier to
contribution fairly high. Quality documentation is hard to get in the first
place, so I want to keep the barriers as low as possible and still keep a
high level of quality (no spam)

I would really like you to talk about what it takes to manage a fork of a
project. Maybe some of the technical as well as the political aspects to
it, and how to make it last long term.

Is there a need that has not yet been addressed by open source?  

Maybe open source had touched every need.  Sure there is room for
improvement on every front.  Where is open source still lacking?  

Corporate acceptance is one area  that comes to mind.  My personal
experience is that a company will spend big bucks for a proprietary
solution before will even consider a solution based on a community approach.

I would like to here where you guys think the emphasis should be.

Thanks

This summer Fitz talked a little to me about setting up a foundation or other 
kind of formal 
organization for open source projects. Could you guys talk about some of the 
advantages and 
disadvantages of doing so for the benefit of the world? I remember you had some 
really good 
insights, including some things I never would have thought of.

From Jelmer Vernooj, on Ben's private blog:

 I would be interested to hear your thoughts about release management. When
is the right moment to put out the first release of an Open Source app? How
often to release? When is the right moment to release “1.0″ ? What about
timed releases? 

This is an extremely high-level question... 10,000 feet up, feel free to
ignore :-)...

One thing that strikes me (especially after working at Google) is that the
way of programming we grew up with is going to be extinct soon.  Basically,
we used to write code to either run on a single machine, or to be
client-server (which is really another way of saying "We're writing code to
run on a single machine -- twice!").  Sure, the code might be
multi-threaded, but basically it accesses a single local data store, it has
one memory space, and the algorithms more or less do a single step at a time.

That's all changing.  The big web companies have server farms, and parallel
APIs for programming those farms.  These days, this is where most of the
exciting developments are, for hardware design, language design, data
structure and algorithm design.

But it's hard to learn programming from the ground up on massive clusters,
because most kids in their bedrooms (or dorm rooms, whatever) don't have
access to clusters.  It's like learning to be an orchestra conductor: you
practice in front of the mirror for months and months, and then
occasionally you get ten minutes on the podium in front of an actual
orchestra :-).

(I'm getting to the question, don't rush me...)

Open source has grown spectacularly over the last ten years mainly because
people from different organizations were a) using the same tools and b)
doing similar things with them.  Apache HTTPD flourished because everyone
had to run a web server, and everyone had access to the Apache sources;
there was a lot of pressure toward inter-organizational cooperation.  (We
could list many other examples, obviously.)

Today, people solving the same problems are *not* necessarily using the
same tools.  Instead, each company is rolling its own, designed for its own
peculiar hardware arrangement.

Do you think this is a temporary blip and that standards will emerge soon,
and that therefore we will see the Massively Parallel world suddenly
floodfill with open source tools too?  Or is open source going to be
confined to being the glue between custom (and usually propriately)
components?  Will open source take over the desktop only to discover that
the desktop doesn't matter anymore?

I'm partly asking because you're at Google, and may have unusual insights
on this.

nt