Twitter github

Posts Tagged with “open source”

December 3, 2014
No Comments

Naming Mars+1 (2016 @EclipseFdn Release)

By

It’s that time of year that members of the Eclipse Foundation Planning Council help spearhead the community-based naming process of the next Eclipse release (slated for 2016).

The rules are contained in this bug where you can submit names for consideration. Here are the guidelines for names:

The rules and procedure for naming Mars+1 will be similar to what has happened in the past. The name should be alphabetically greater than “M”

Preference will be given to “N” names, but no strict rule that others would not be considered. Preference given to names that fit the “moon”, “heavenly body gods”, or “scientists” themes we’ve had in the past.

I’m suggested Nova or Neutrino to start, but have taken a liking to Neptune as a potential option:

Have a better suggestion for a name? Well put it in the bug before we call for an official vote in the coming weeks.

Thank you!

 

November 7, 2014
No Comments

Open Sourcing the Twitter Emoji

By

Usually I’m buried in the realm of just code, but yesterday I had the fun job of open sourcing the beautifully designed Emoji set we use at Twitter:

Why does this make me happy? First off, emojis are fun, hugely popular and standardized by the Unicode Consortium. One of the interesting sites I came across was EmojiTracker which shows real time emoji usage across Twitter.

Finally and more importantly, emoji have been historically plagued by licensing issues. Due to some of these concerns, WordPress reached out to us to see if we were interested in collaborating and opening up our emoji set. We thought this was a great idea, so here we are today.

In the end, my hope is that us sharing our emoji with a permissive license will help alleviate some of the IP issues and help open up the web a little bit more for everyone.

June 15, 2014
No Comments

Mesos at Texas Linux Fest 2014 (#TXLF)

By

At Twitter I have the fun job of running our open source office and I recently had the opportunity to present about one of our infrastructure projects (Mesos):

Thank you to the organizers at the Texas Linux Fest for hosting a great event and I look forward to it growing more next year.

 

 

 

November 26, 2012
No Comments

Open Compliance Summit Asia 2012

By

Last month, I was grateful to have the opportunity to present at the Open Compliance Summit hosted by the Linux Foundation.

As some of you may know, a portion of my current job at Twitter is defining our open source strategy and compliance efforts. While at Twitter we’re fortunate that compliance is less burdensome than at some other traditional companies who have many distribution points (e.g., devices), nevertheless it’s still important to respect licenses and the software authors intention. We mostly run on open source software and are cognizant of the benefit we receive from a variety of open source communities and what it means to give back. We also don’t mind sharing what we develop, on top of preferring liberal licenses as that helps with adoption (and also makes compliance less complicated) in my opinion.

At the end of the day, it was a great event bringing together participants from different companies to discuss open source compliance issues and best practices. Thanks again to the Linux Foundation for hosting the event.

April 2, 2012
No Comments

Summer of Code 2012

By

It’s that time of year, where post-secondary students get to apply to their favorite open source organization for Google Summer of Code (GSOC). Essentially, Google pays students to hack on open source projects over the summer, which is just amazing.

As a student, you get a stipend of of $5000 USD and the respective mentoring organization gets $500. Students have from March 26th through April 6th to apply to the mentoring organizations that they are interested in. Afterwards, the mentoring organizations rank and review the proposals. Finally, the accepted proposals are announced on April 23rd.

If you qualify (you’re a student and older than 18) and have some coding skills, I highly recommend you consider doing GSOC as it’s a great way to learn something, get some experience and even get a job potentially. I recommend looking over the list of mentoring organizations. I’m excited this year because Twitter is a mentoring organization and we will have some students work on some of our open source projects. Of course, the Eclipse Foundation is participating and has a great list of project ideas.

In the end, if you’re a student, just do it if you don’t have anything else crazy lined up. You get to work with quality mentoring organizations that have been vetted as great places to get started on working on open source.

October 23, 2011
No Comments

Open Source: Interacting with Contributors

By

I recently came across Michael Meeks’ most excellent and brief presentation on interacting with developers. It embodies a philosophy of mine when working in open source, to kill people with kindness. However, his analogy of relating code contributions to pictures drawn by children works well in my opinion…

The slide above reminds me of Maddox’s classic rant on kid artwork.

Thanks for the great analogy Michael, I completely agree with you!

June 1, 2011
2 Comments

Releasing in Open Source and at Eclipse.org

By

Releasing software is a bit of an art form and everyone has different philosophies, especially in the realm of open source. For some people, releasing something every week is critical, some people want to release consistently on-time and others simply never ship. We also have to be mindful that releasing software means different things in different communities. In mature open source communities like Apache and Eclipse, you’ll find more formal processes to deal with when announcing a release, whether it’s incubating or mature. I have a personal philosophy that shipping is everything, probably a remnant of my heavy involvement on the Eclipse platform team, but that’s a topic for another day.

Inside the eclipse.org community, there’s been some discussion lately about scheduling releases. Historically, the Eclipse platform ships a major release every year (triggers a release review as part of the EDP) with six-week milestones in between. Also, the Eclipse platform project aligns itself with the annual simultaneous release (e.g., Indigo). I think this works fine for the platform project because it’s extremely mature and dependent on by a lot of consumers. However, I would love to see the platform release more than once a year, but I haven’t had enough time to think about how to do that without being very disruptive. It is something the project leadership should be thinking about as we move into the 4.X Eclipse stream.

Since the Eclipse platform project is very prominent, a lot of other eclipse.org projects tend to align their releases with the platform. I think this is wrong method to choose your release schedule, especially if you’re a young project. Actually, some people I have talked to think that they only have to release once a year, which is wrong as the EDP doesn’t impose any major time restrictions on you releasing. I think each project should release according to its maturity level and adopters needs. For example, let’s look at the Mylyn project’s release history…

  • Mylyn 3.6.2 (February 24, 2012 – Indigo SR2)
  • Mylyn 3.6.1 (September 23, 2011 – Indigo SR1)
  • Mylyn 3.6 (June 22, 2011 – Indigo)
  • Mylyn 3.5 (March 16, 2011)
  • Mylyn 3.4.3 (February 25, 2011 – Helios SR2)
  • Mylyn 3.4.2 (September 24, 2010)
  • Mylyn 3.4.1 (August 4, 2010 – Helios SR1)
  • Mylyn 3.4 (June 23, 2010 – Helios)
  • Mylyn 3.3 (Oct. 26th, 2009)
  • Mylyn 3.2 (June 24, 2009)
  • Mylyn 3.1 (March 4, 2009)
  • Mylyn 3.0 (June 25, 2008)
  • Mylyn 2.3 (Feb. 27, 2008)
  • Mylyn 2.2 (Dec. 19, 2007)
  • Mylyn 2.1 (Sep. 28, 2007)

If we notice a pattern, Mylyn tends to release about four times a year and tries to align itself with the annual release train. Another example is the EGit/JGit projects…

  • EGit/JGit 0.7.1 (Mar. 22, 2010)
  • EGit/JGit 0.8.1 (Jun. 2, 2010 – Helios)
  • EGit/JGit 0.9.1 (Sep. 15, 2010 – Helios SR1)
  • EGit/JGit 0.10.1 (Dec. 17, 2010)
  • EGit/JGit 0.11.1 (Feb. 11, 2011 – Helios SR2)
  • EGit/JGit 0.12.1 (May. 2, 2011)
  • EGit/JGit 1.0 (Jun. 1, 2011 – Indigo)

The EGit/JGit project tends to release every few months and tries to align itself with the annual release train.

What’s your ideal release schedule? If you’re an eclipse.org project, why don’t you release more often?

September 2, 2010
5 Comments

The Value of Documentation in Open Source

By

I’ve been starting a lot of documentation work lately for the EGit/JGit projects and happened to come across this timely article from Forbes. If you don’t want to read it, the gist of it is that solid documentation is more important than you think… especially when it comes to attracting a user and developer base. Here are some quotes…

“I can report that my company receives 70% plus of our site traffic from organic sources, and our documentation generates more than half of our overall site traffic. Furthermore, over half of our lead generation is driven by our documentation.”

While the article specifically mentions commercial software, I think the lesson of having solid and findable documentation apply to the open source realm. I mean, when’s the last time you’ve come across an open source project that you praised their documentation efforts? I can maybe count two total in my lifetime. As open source developers and project leads, we tend to put documentation last and our expectation is that users would pitch in to help. As users, we just want good documentation and don’t believe it’s our responsibility to help out necessarily…

So next time you’re working on that feature, weigh it versus taking some time to document things for your users. If you’re in Eclipse land, feel free to take a look at our documentation guidelines and some examples on how to crowdsource your documentation efforts a bit.

June 1, 2010
11 Comments

Marketing in Open Source

By

Over memorial day weekend, I noticed that the Apache Software Foundation is having a little fun with marketing over Twitter.

I’m a fan of their “Did you know…” series of posts as of late. I mean, I had no idea Apache Shindig is the foundation for the LinkedIn InApps platform… and I’m sure the folks at LinkedIn wouldn’t have told me in a straightforward fashion either. I mean no offense to the folks at LinkedIn and other companies that use open source software, but they generally don’t do the best job advertising the open source technology they use. Sure, some companies are better than others but my point is that the burden of marketing seems to fall on the open source projects themselves. The problem with that is that open source developers are generally terrible at marketing (well, mostly apathetic). And I can guarantee you that if no one talks about your project or can find it, no one will be really using it even though it may be a great piece of work.

At Eclipse.org, I know this has been a bit of problem given just the diversity of projects and from people who have spoken to me. The Eclipse Foundation has done a good job when it comes to case studies on people building upon the Eclipse platform, but what else can it do for projects? From my own experience in supporting people who use Eclipse technology in the field… it’s quite amazing where you see Eclipse technology turn up… from ski lifts to banks to rail way systems. I don’t think many people understand the breadth of places that Eclipse technology shows up. Just a couple days ago I learned that Xtext was helping the automotive folks at AUTOSAR.

If the burden of marketing falls to open source projects themselves, what can you do to convince people to “sell” their project a bit? Should we suggest webinars as something people do as part of the release review process at Eclipse? Should a book be required as part of a graduation review at Eclipse (ok, maybe that’s a bit much but I’m still waiting on my Xtext book)?

Just some food for thought.

May 5, 2010
8 Comments

The Open Source Developer’s Dilemma

By

Over a couple frosty beverages yesterday, I had a lively discussion with a colleague about open source contributions from a developer’s perspective. In my opinion, open source developer’s have to walk a fine line when it comes to working with new contributors and not killing all of your time while doing it…

What do I mean here? Well, when you get a contribution it’s pretty rare that the contribution is just perfect and ready to be submitted to the main line. The reality is that you get contributions that generally need some form of tweaking before they are ready for the world. It’s the tweaking where things get interested. There’s two attitudes you can generally take.

The first position is you can simply be happy that you got a contribution in the first place and just make the necessary tweaks your self and push it to the mainline. The upside to this is that the contribution actually gets contributed quickly. The downside is that this consumes a bit of your time to polish the contribution and that you may also miss out on the opportunity on cultivating a contributor. The second position is that you can do a thorough review of the patch and force a contributor to polish the contribution to meet your standards. The upside is that your this may result in higher quality patches from contributors in the future. Heck, if contributors become really good, they may even make the jump to a full blown committer on your project. The downside is that patches may go stale because you may discourage contributors if you ask too much from them.

I’ve seen both approaches in a variety of open source communities. I’m generally happy just to get a contribution from anyone. I don’t think there’s a silver bullet approach in the way you treat contributors, you probably have to do things on a case-by-case basis. In the end, I felt like I needed to do a brain dump of the discussion I had yesterday. On top of that, I find the question of how to attract contributors without killing all of your time while keeping quality high… just fascinating.

What do you think about this problem… from either a developer’s or a contributors perspective?

« Older Entries
Newer Entries »