[...trying to move the whole dLoo thread to the mailing list where it belongs, sorry to be so disjointed and include messages from everywhere...] Nile wrote: > Greetings from dLoo, Hey Nile. Thanks much for writing and for the time you guys took in preparing the "gray papers." It is very nice to have someone spending time looking at Piper ideas enough to write up documents like those, so that is very cool, and much appreciated. In addition, thanks for all of your responses to Jeff's questions concerning licensing and your company and all of that stuff. I'll admit that I'm one of the people with a lot of concerns about working with a company. In general, companies and business in general make me feel sick to my stomach, but dLoo's hands off approach sounds very cool, and since you guys aren't that big, I guess I can leave you off my list of companies to destroy and burn :-). Seriously, the kind of informal relationship Nile was proposing sounds really good. Nile wrote: > So, I have a serious question for you. We're looking at the "gifts"/"grants" > approach to avoid these effects? What do you think of this? Is it > sufficient? In > short, what is the best way for a cash-poor company to support open source > developers? I don't really know if I am a good person to be answering this type of question, since I don't need to make any cash from open-source programming (at least right now :-). In addition, I'm not too positive I feel very comfortable speaking for any part of the open source community. Maybe stuff like this would be good to bring up on some KDE and Gnome lists? It seems like there are always lot of people ready to spout off about their open source ideas, and this might manage to grab people more from the "mainstream" open source community, whereas I feel like I am kind of on the fringe. Nile wrote: > We are learning a lot over here. One thing the community really lacks right > now is a document that explains how companies should work with Open > Source. E.g., a FAQ that has answers to the question "How should a > company contribute to an open source project?" or "How should a company > collaborate with an open source team?" This is a hard question to answer in general since it probably varies a lot from person to person and project to project. For me, I would just be happy to be coding on open source projects alongside people from companies. I don't really understand any of the details of how a buisness works and stuff, but it seems like the best way to have a company collaborate with an open source "team" is just to have people from the company coding/talking about the project, just like any other random person. One thing about open source is that no-one should really "control" it (of course, as Nile mentioned, this doesn't always happen, like in the case of Mozilla). The project is more about a bunch of people with similar ideas coming together, coding, and producing a product without any restrictions on it. So I would be more than happy to code along any with anyone, even if they are from a company. I guess the mess comes in when people need to use the product to make money, and this is where I am not really 100% sure what the company needs to do and how this will affect the relationship of a person from a company and an open source team. So I don't know if any of that rambling was any help on that, but now I'll talk about something more important, Piper and dLoo/BlueBox collaboration :-) > ---On Collaborating as a Whole--- Gary wrote: > So here we are considering another > collaboration, which means another rewrite of our defiinition layer to > hook into the bluebox system. Gawd no! Excuse me for a second while I get a couple of shots of "Old Crow" to deaden the pain here.... Seriously, I do not mind rewriting the dl to incorporate new code (even tho I bitch and moan about it all of the time). I have got so many cool ideas from Jarl and Jean-Marc's stuff and I think Piper is benefiting greatly already from their contributions. Hopefully soon we'll have hooked a lot more of their code into all of this and this will be really apparent in actual functionality :-). But the dl is written in python, which is meant for re-writing and messing around with things (if it was in C++, I definately would have gone completely insane by now), and we should take advantage of that to try to hook more stuff in, if we can. Sigh, did I really say that? :-) Gary wrote: > We stand to benefit from the expertise of > the dLoo programming team, and the codebase that they have produced. Agreed, there are tons of good ideas there, and it is definately easier to hook in good ideas than to write 'em from scratch. I don't really 100% understand what dLoo "wants" from Piper, but if we can take advantage of code they have, this is really super. Gary wrote: > But > without having a good look at that codebase, it is hard to guage how much > work we would be required to do in order to justify the collaboration. So > before we can commit to a collaboration, I think we need to have some idea > of the extent of revision we will have to do in order to integrate > bluebox and piper. Agreed completely. It is hard to talk about anything without seeing actual code and functionality and figuring out where it'll go. I'm presuming that BlueBox is written in C++, and I've already gotten SWIG to generate working bindings for Jean-Marc's code, so technically this hopefully won't be too much of a problem (as long as they don't use too much STL, ugh!). However, I think our number one priority should be getting Overflow and GMS integrated with what we've got in Piper. This is really coming along thanks to Jarl and Jean-Marc's hard work, and I want them to be able to have something working as soon as we can. It seems like this isn't too bad with BlueBoxes time frame, since there won't even be an initial release until later this month. So that should give us time to figure out how we are going to actually work on integrating the two projects together while we work more on getting Overflow, GMS and Loci all together into Piper. It would definately be great to see BlueBox code as soon as we can, so we can try to migrate what we have to fit it, and make things less painless. But, damn, who is going to do all this work I just talked about? :-) Nile wrote: > ---On the Gray Papers--- > > What we have been doing over here the last two days is putting together > a set of gray papers (not white) on how BlueBox works, how we understand > Piper to work, and how they could work together with directory services. Again, thanks for doing this! It seems like quite a bit of work and is much appreciated. Here's my thoughts/comments on particular pages: 1. The Piper screenshots on dev_graypapers_piper.html and dev_graypapers_user.html -> These screenshots are crustily old (did Piper/Loci ever even look like this, or is this all just mockup?). Can we give the dLoo guys some real screenshots from what we have now that shows the same stuff? I can do this, but am probably not the best person to since my artistic skills are nearly nonexistant. This way we can also show multidimensional components in action and everything. Another point on this. I *hate* the screenshot/mock-up with the "MultiSeq" sequence alignment node on it, just because it isn't even close to a good reflection of the functionality we have in Piper right now. If we want to use this, I would be much happier if it was clearly labelled as just being a photoshop job and not reflecting current functionality. I just think it gives people the wrong idea about what we've got. 2. The mention of a "XML component language" at the top of 'dev_graypapers_piper.html' and 'dev_graypapers_user.html' -> I am kind of nervous about calling this "a complete language" since the XML here is really simplistic. Right now we are just modeling each node/locus as having three items: Parameters, Inputs, and Outputs, and trying to make things fit in as having only these three items. I don't know if we can make any promises that this is scalable to incorporate "any component" that exists, since we just started using this new language a couple of weeks ago :-). This is all based on functionality that already exists in Overflow, so it is very promising to work well (at least, I hope so), but maybe we could talk a bit about this "three component model" or whatever and mention that is what we are doing. I could write something short up on this if you all want... 3. On the DSML stuff at 'dev_graypapers_dsml.html' -> For the Status part, unfortunately no actual code exists in Piper to support networked connections and sharing of directory services :-<. Sorry to disappoint. Right now we've been focusing on local stuff only (even though my real interest in this is in the networking). How the networked stuff is proposed to work is semi-sketeched out in the docs on the Definition Layer. I was hoping this wouldn't be too horrible to implement since it would be built off the framework that already exists in the definition layer (so at least it wouldn't be from scratch) but I'm afraid I can't claim that a single line of code is specifically devoted to networked connections :-<. Since this is the case, I had a nice read through the DSML spec that Nile et al. reference on this page (Minor rant--why can't they have one example in this stupid spec that doesn't have ugly namespaces cluttering it up? :-) and it seems like a really cool way to mark-up available directories (well, nodes or loci in the case of Piper) and what kind of functionality they have. If you guys at dLoo have a plan sketched out for how you want to incorporate the remote directory services, it would be really nice to be able to talk through this and see if we can bounce ideas off of each other. Okay, I'm going to stop writing now. If you made it all the way to here, you should definately give yourself a bit fat gold star. Thanks much for reading. Brad