acquire Shields #1307
Comments
|
Hmm... while I have no real objections to the "acquisition" of Shields, I do find the reasoning off. 😄 For the first three of the reasons you mentioned:
As a side note / food for thought: you're doing this in name of the Gittip organization right? Who is part of the decision making process in an Open Company? Just the formal employees? Are Gittip.com team members also its formal employees? If Gittip.com team members are supposed to be formal employees of the company, are they automatically part of the decision making process? What is the decision making process? I guess what I'm saying is, there's a difference between being Open in terms of sharing information and being Open in terms of decision making. Do (should) Gittip.com team members have a say in "company decisions"? |
|
@mvdkleijn We're using the term acquire in a cute way. I enjoy the initiative @whit537 has brought to Shields and I'm especially sensitive to anything that could increase the usage and visibility of both projects. As something that naturally brings open source contributors and the people who benefit from open source together, it seems very natural for me to have Shields be an example project for Gittip. Chad offered to make Shields a part of the Gittip organization at a time when he contributed and led the project far more than I did. I'd rather see the goal I pointed to (better meta data about open source projects) be achieved rather than clinging to attempt to do all of it myself, especially considering my audience is far more limited. Shields was the first open source project I created where I trusted the community to understand my vision and help me achieve it, and boy did that pay off. A few months after the angry Photoshop session that led me to produce the first PNG Shields, you can see Shields badges used on a staggering majority of the most popular open source projects out there. I wish I had stats to know how many (which is why I'm so excited about the Shields.io API) but I could never have achieved that in such a short time on my own. I believe making Shields a part of Gittip will bring about even more amazing contributions to this project. I can be wrong, but I don't think my reasoning is off. 😃 I can't speak for Chad when it comes to the way he decides to run Gittip. From my understand he tries to be as open as possible with his communication, and with the reasons behind his decisions so his motivations are transparent. That seems important when dealing with something as crucial as donations, which obviously involve money. As for decision making, I'm a huge partisan of letting the best idea win. Which in turn making it as easy as possible for people to offer the best idea. That's different from design by committee, which would be letting everyone have the same weight in judging which idea should prevail. It would be obvious, in my mind, if the final decision maker repeatedly (or often) picked the idea that was overwhelmingly seen as the worst one by the community. And that would be to detriment of the final decision maker and the project itself, if that was done often enough to alienate the community. Anyway, as I said, this is a question best answered by @whit537. |
@mvdkleijn Well, those are the secondary reasons. The primary reason I gave is that "Shields is a great example of the kind of service that should be able to be funded on Gittip, and having one such service in house gives us a chance to try it out, eat our own dogfood, drink our own whiskey, feel the pain, drive best practices, etc. etc."
Yup! :-)
You are! Thanks for chiming in! :-)
Well, Gittip is run like an open-source project, which means that the whole Internet is invited to be a part of Gittip's decision-making process. As @olivierlacan points out, this doesn't mean that everyone's view carries equal weight. Gittip's decision making process is benevolent dictatorship (though, as @kfogel points out in his book, open-source projects tend to settle into democracy as they mature).
Everyone has a say in company decisions. The naming ticket (#138) is probably the best example of this for Gittip so far. @mvdkleijn I was actually getting ready to close this ticket until you chimed in (as @kfogel also points out, silence == consent). Have we convinced you that this is a good idea, or do you still think it's a bad idea? |
|
Last call! |
|
Fine by me, just had some questions. (I tend to gravitate towards supplying a ’critical note’ attitude when I am involved actively in an open source project I'd like to succeed) |
|
Thanks @mvdkleijn. The critical eye is welcome here. :-) |
|
💃 |
|
I think Gittip is great and love how you're running it, but would like to make a category distinction: Gittip as a service & an organization, isn't -- and can't be -- open source per se. It can be transparent, democratic, and many other good things, but it will have have very different dynamics from an open source project. Open source is completely dependent on having easily replicable resources (in economic terms, "non-rivalrous" and "non-excludable" resources). It depends on people's ability to copy (data), to modify those copies, and to merge modifications between copies, at essentially zero physical cost. There may be a time cost for those doing the work, but they make that decision independently; there's no step at which permission or group agreement is strictly necessary. Scarce resources -- such as physical goods, money [1], and trademarks/identities, for example -- do not have these properties. Food is non-replicable; same with kitchens, bicycles, etc. On the other hand, code, documentation, and ideas are replicable. Sometimes people use the word "sharing" to refer to two different things: offering up something for someone to make a copy of ("let me share these pics with you") and letting someone use or consume a physical object ("let's share this bottle of wine"). But that's just terminological overloading and doesn't mean they're the same kind of action. Open source is entirely about the copyable stuff, and all the recommendations in my book (which I'm flattered that you cite) are about organizing people to cooperate on that kinds of project. In particular, the so-called "benevolent dictatorship" model is stable in open source only because of forkability. Gittip is great, but it's making decisions about non-replicable things, so while it may support open source , it can't itself be open source. That's okay -- there are many good things in the world that are not open source! :-) And you might continue to be a terrific benevolent dictator despite the lack of forkability, just due to your own personal integrity. But that's a happy accident, not an outcome of the situation's dynamics. So I'd be cautious translating the advice in my book to situations that can't really have open source dynamics. Maybe some of it'll work sometimes, but much of it won't translate directly, I think. Open-source style governance and collaboration methods are totally dependent on that copyability property. The governance and decision-making processes needed to allocate scarce ("use-up-able") resources are different from the methods that work for non-scarce resources. Keep up the good work! Best, [1] If anyone's thinking "Wait, but I could copy money!", please see http://questioncopyright.org/faq#fraud :-). |
|
@kfogel Thanks for stopping by! :D
Can we dig into this a little further? What are the non-replicable things Gittip is making decisions about?
Gittip, LLC doesn't own any physical goods, nor any trademarks (our logo is in the public domain along with the rest of our digital assets). Yes, we have a little money in a bank account, and we have password-protected accounts with service providers such as Heroku, Balanced, Twitter, Tumblr, etc. We also have control of a domain name. But what open source project doesn't have these things? Do you make a distinction between an open source project and the infrastructure for that project? Thought experiment: What might it look like to fork Gittip? I imagine one would click "fork" in GitHub, and set up alternate infrastructure to host the new fork. Of course the fork couldn't live at www.gittip.com, but then again a fork of Apache HTTPD couldn't live at httpd.apache.org. The fork couldn't pay for its infrastructure with money from the original project's bank account, but, again, that's true of forks generally. I'm not convinced that Gittip isn't open source. :-) |
|
Essentially, your trademark (== your reputation): people's trust that gittip will pass along the money as stated. That reputation, attached to the name "gittip", is primarily what gittip is, and isn't forkable. When you say "Everyone has a say in company decisions", I take you literally :-). |
My intention is for Gittip to not have any trademarks. :-) We've already had cases of companies using the Gittip name and logo without coordinating with us ahead of time: We haven't stopped them.
Okay, but since Gittip's source is open, doesn't that provide the guarantee that we work as advertised? Anyone can inspect our payday algorithm. Of course, since we control a system on which the payday algorithm periodically runs, we could modify that algorithm before running it. Perhaps the algorithm in our repo isn't the algorithm we actually run. But then, Apache HTTPD could distribute a binary with malicious code in it. We trust them not to because of their reputation—a reputation which is not forkable.
Is there a difference between binaries and a hosted installation that makes Apache open source and Gittip not? |
|
I think the point @kfogel was making isn’t the reputation of the open source project itself or the quality of its code, but rather the reputation of the instance of that project / code in the form of the functional www.gittip.com website. Anyone could indeed copy just about anything of Gittip, down to even its name if they so desired. However, a complete clone of the site & project / company would both be impractical if not impossible as well as useless. The necessary differences would lead a user too correctly conclude he's dealing with someone else. That other entity would be starting with a near zero reputation because a user can't be sure the new site would adhere too the original’s standards, practices and ideals. It is a user's trust in those standards, practices and ideals, amongst other elements like people, that make up an organization’s reputation. @kfogel Correct me here if I understand you incorrectly. 😄 Sidenote: interesting discussion... |
|
@mvdkleijn That's right. @whit537 Think of it this way: Apache HTTPD is an open source project; the Apache Software Foundation, however, is not. When the ASF spends its finite resources to acquires property, it has various decision-making processes, involving the Board, and perhaps the members, and those processes might be very democratic, transparent, etc... But they're not open source, because the ASF is not an open source project. When Apache HTTPD, on the other hand, chooses (say) to include or not include feature X in a release, that's a decision being taken by an open source project, using open source governance methods, in the full knowledge that if someone really disagrees with the result they can fork the project. The reason I commented here is that it seemed to me the topic under discussion was more of the former type than the latter. Incorporating Shields' functionality into gittip's code base is an open source project making a decision in the usual open source way, sure. But spending gittip's money / organizational resources / whatever to "acquire" Shields is an org making a decision in an org-y way. The two are related, of course, but they're not the same thing. One is an open source project, the other is not -- and the application of "open source" governance principles to the latter type doesn't fit, IMHO. Again, I'm not saying anything is wrong about the decision, and I'm certainly not arguing against the admirable transparency and the broadly consultative methods with which gittip-the-org does things in general. That's all great! It's just orthogonal to open source. |
|
@mvdkleijn When DragonFly BSD forked from FreeBSD, didn't they have a reputation problem to overcome? Isn't that kind of the essence of forking? The forker decides that the parent's reputation is questionable enough that it's worth it to build a new reputation from scratch. Of course, it's not *really" from scratch, because the leaders of the fork are probably known to others in the project and, for the fork to succeed, probably actually represent a sizable minority if not majority of the project. |
|
@whit537 By the way, I was using the term "trademark" conceptually, not legally. If someone else started posting on Github under the name @whit537 (assuming that were somehow technically possible), even though you haven't registered a trademark on that name, it would still be an identity confusion, and that's what trademark is about. IOW, it's just a synonym for "recognizability+reputation". A formal trademark is just a legal enforcement mechanism for something that is also often enforced in an informal and decentralized manner. Someone using the "gittip" codebase and labeling it as such is not the same as someone claiming to be gittip. I use Drupal, and might have a "powered by Drupal" button somewhere on the front page of my site -- fine. But if I started claiming to be the Drupal home page, the Drupal Association might want to have a few words with me :-). And independently of the DA, the Drupal community and Drupal users in general would start condemning me. Once you make that distinction, I think my earlier comments might be clearer. |
|
Okay, so Shields is the scarce resource? Gittip's acquisition of Shields precludes other organizations from acquiring Shields? Maybe. Though Shields is an open-source project, and any other organization could fork it and have their own. Right? :-) |
|
I saw the words "acquire" and "sell" used (as opposed to just "we're going to use Shields", i.e., use the Shield's code base in what we do). If there wasn't any allocation of scarce gittip resources here, then all my comments are moot (but someone was describing things inaccurately ;-) ). |
Well, I'll leave that up the Drupal Association to decide. But if you buy gittip.asia and start claiming to be the Gittip homepage, I won't stop you. I'll suggest that we link to your fork. :-) |
|
@kfogel No money changed hands. That doesn't mean it wasn't an acquisition. ;-) |
|
I suspect that if a bunch of people registered gittip.* and started impersonating you but not distributing the funds in the way they claimed (or doing something else to damage the Gittip org's good name), you'd start to get concerned pretty fast. Re "acquire": this is a rather unusual use of the word "acquire" and I don't fully understand what you meant by it, then. It certainly misled me. |
|
Also, why in the heck would you automatically be willing to link to or otherwise endorse people who just happen to use a certain string of letters? Does the substance of what they're doing not factor into your decision at all? :-) |
Fair enough. :-) As @olivierlacan says above, "We're using the term acquire in a cute way." I like to see our use of the term in the broader context in which Gittip is gently subverting certain accepted notions. It parallels the sense in which we used the term "hiring" back in January I haven't read Down and Out in the Magic Kingdom yet, but I want to, because I expect to find resonances in whuffie with how Gittip is approaching hiring and acquisition. |
My goal in this case will be for us to live up to the words of Neitzsche:
If Gittip succeeds we'll surely be given the chance. :-) |
I can imagine us distinguishing between good faith forks and malicious impersonators. It's harder for me to imagine spending time and energy attempting to track down and punish the impersonators. |
|
That's precisely a question of how to allocate scarce resources, yes :-). I feel obliged to point out that Nietzsche went insane. |
When members of the Apache HTTPD project decide how to spend their time and energy on the Apache HTTPD project, are they allocating a scarce resource that belongs to the Apache HTTPD project? |
|
No, but they don't typically initiate a community consultative process when they make those decisions either. |
|
By the way, I know I've said this in some of the above comments, but I want to emphasize: none of this is criticism of gittip -- it's just an abstract discussion about organizational methods and collaboration (all the more abstract now that I know it was based on a misunderstanding on my part). Gittip itself is great, and so is the way you're running it. I still think that part of it is not an open source project, but that part turns out not to have done what I thought it did w.r.t. Shields. |
|
@kfogel If we're going to distinguish between the ASF and the open-source projects it stewards, then surely the same applies to Gittip, LLC and its projects. I think it's fun to see how small we can keep the LLC, off-loading the things usually associated with the LLC ... somewhere else. Thanks for having it out here. :-) |
|
If you really want to keep it as open and transparent as you've been doing so far, I think keeping the LLC as small as possible is essential. Also, I think you/we should be writing down some stuff regarding organization of Gittip internals? That will make it easier for new participants in the Gittip organization to know how things have been organized/agreed upon by the current participants. If I'm not mistaken, its now mostly assumed behaviour and/or in the head of @whit537 ? For me personally, one thing I'd write down is the "silence == consent" assumption... including a defined term within which people should be responding. That'll make it more obvious about when something is finalized and prevents problems with, for example, people being on holiday and coming back after a few weeks to lodge a concern, thus frustrating the decision making process. Assuming I'm making sense here. 😃 |
|
Totally agree about keeping the LLC as small and lightweight as possible, for the reasons you say. Keeping as much of gittip in the "open source project" realm as possible seems like a good strategy to me (and seems to be what you've been doing, too). |
|
@mvdkleijn Have you read @kfogel's book? He's already written down a lot of things, including, "silence == consent," and also, under "Writing it All Down":
:-) Might want to wait for the second edition, though. |
|
Of course, he also says not to have conversations in the bug tracker. ;-) |
|
@whit537 No I haven't. I usually find books about this stuff bores me to soul destroying tears. :-P However, I'm pretty sure he doesn't say "document nothing" which, unless I'm mistaken, is the current state with regards to Gittip.org organization. Apart from some generalized remarks on what an open company is in your view I believe? |
|
Not trying to be comprehensive I fully agree with by the way... that's near impossible. I was talking about writing down "known internal conventions" (general rules of decision making and interaction as agreed upon by the community/organization in the past). A ten commandments of the Gittip organization as you will. |
|
@whit537 Hah, now you're baiting me -- I was already planning to update that "no conversations in the bug tracker" thing, since trackers and their usage have changed since then :-). (But you probably knew that, as I mentioned it in a recent backer update.) Documenting the basics of how gittip decisions are made might be a good idea. Even just an explicit statement that it's a benevolent dictatorship where the dictator actively solicits feedback and advice gives you something to point to when people ask how the place is run. |
|
:-) I'm very much looking forward to the second edition, @kfogel. I took the first edition with me on vacation last month and it has had a big impact on me in terms of how to build the team that's building Gittip. The most immediate practical change is that I stopped hacking directly on master after reading your book and started submitting to the same pull request workflow as everyone else. No-one would merge my pull requests until the site crashed one evening and (after barely stabilizing it) I refused to merge my own pull request to bring the homepage back. "If you all want the site back then someone's going to have to merge this pull request!" It worked! 💃 As far as Gittip docs go, yes we should write a few more things down. We have some tickets open for this and it's a short-term priority. Okay! Let's go write stuff! 💃 !m @kfogel |
|
@whit537 That's a great story! "Site stays dark until someone reviews my code." I'll see if there's room for it in the code review subsection... :-) |
|
:-) |
Over on badges/shields#15 you'll see that Gittip has acquired Shields, as far as @olivierlacan and I are concerned. However, in the spirit of openness and transparency, I'm opening this ticket to give anyone a chance to raise objections to this deal. Sorry we rushed ahead without consulting the community properly. There's a parallel ticket at badges/shields#43.
The main reason for Gittip to acquire Shields:
Secondary reasons:
The plan is to proceed with the deal but leave this and badges/shields#43 open for a few days to surface any objections.
The text was updated successfully, but these errors were encountered: