open source

Read more about the article Open Source Developer Guide and Best Practices at FOSSASIA

Open Source Developer Guide and Best Practices at FOSSASIA

I would request you to please guide me as to how can I collaborate with you and also how can I contribute effectively to the organization.

At times I might get up to 20 private mails per day about “How to contribute to Open Source”. Usually I will direct developers to our mailing list or chat channels if they are asking about a specific project. But, how do contributions work at FOSSASIA? How can new developers join projects effectively? We have tried many different ways and spent a lot of time communicating with newcomers, many of them new to Git and Open Source development.

Over the years we have gotten better at helping new developers, designers and other contributors to join up. We have more than 1300 registered developers in our GitHub organization today. Not all of them can contribute every day, but we do have thousands of commits every year.

So, how are we able to scale up? I believe one reason are our Best Practices. We didn’t have a document “FOSSASIA Best Practices” yet, but in our daily work we have established excellent (mostly unwritten) best practices, that I would like to share in a concise form here now as a reference for new developers.

Happy to get your feedback and comments.

Development Best Practices at FOSSASIA

Culture and Communication

  • Please adapt your language to non-native English speakers and be super friendly. Remember we are an international community with contributors mainly from Asia and Europe. We are not used to swearing and will mostly understand words literally. At all times ensure your tone stays appropriate and friendly in the FOSSASIA community.
  • Stay modest. Sometimes newcomers already have an amazing knowledge in some areas. Still remember, it is no reason to be arrogant. Even the best developer does not know everything.
  • Be nice and welcoming. Why not add “please” in an issue or a comment “Thank you” in a pull request if someone did a good job? Show your appreciation for the good work of your co-developers.
  • If you are involved in a topic you don’t understand yet, try to learn yourself as much as possible from public channels (wikipedia, stackoverflow) but also do not hesitate to ask questions to other developers.

Communication Channels

Every project at FOSSASIA has its own channels. Many projects use Gitter, some Slack or IRC. Usually you will find information of the main communication channels of a project in the Readme.md.

While we are a community of Open Source and Free Software developers we still reserve our right to use whatever tools we deem necessary to help us to achieve our goal of developing the best possible Open Technologies – software and hardware. It is one step at a time 🙂

Private and Public Chat or Issue Tracker

Chat is a great way to connect with other contributors, but not all contributors are there all the time (consider time difference and personal schedules) and they are not always available to chat. Chat tends to be unstructured and with lots of people in a room there are often a number of threads. Therefore chat is great for help on setup issues and things where you got stuck.

Do not use chat for feature requests and detailed discussions on issues. These things are best for the issue tracker, where people from different timezones can join and where a focused conversation on one specific topic can happen.

Some people try to overcome the unstructured chats by switching to private communication. This shuts out other contributors who might have similar issues. A result I often observed is also, that contributors will bring up arguments in discussions like “I have discussed this already with xyz privately and he agrees”. Other contributors have not seen this discussion if it has not been taken place in public and we haven’t seen the arguments. We don’t know if xyz really agrees or if it was misunderstood. Private conversations are not transparent. Surely, there are cases where private chat is needed, e.g. for specific deployment questions of projects, but whenever you talk about development, please switch to public chat or open an issue.

Feature Requests and Bug Reports

  • Some newcomers are not accustomed to issue trackers and might try to inform developers on the mailing list, chat or even write private emails about bugs and features, but the right place to do this is: The issue tracker of a project.
  • Any bug or feature, please open an issue in the issue tracker right away and indicate if you want to work on it yourself.
  • Please include all relevant information when you submit an issue and wherever possible a link, information about the code that has issues and a screenshot.
  • When you file a bug report on the issue tracker, make sure you add steps to reproduce it. Especially if that bug is some weird/rare one.

Join Development

  • Before you join development, please set up the project on your local machine, run it and go through the application completely. Press on any button you can find and see where it leads to. Explore. (Don’t worry. Nothing will happen to the app or to you due to the exploring. Only thing that will happen is, you’ll be more familiar with what is where and might even get some cool ideas on how to improve various aspects of the app.).
  • If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please free to drop in a comment so that the issue can be assigned to you if the previous assignee has dropped it entirely.

Commits/Pull Requests

  • All pull requests need to be associated to an issue.
  • All PRs need to be assigned to the person working on it.
  • If an issue cannot be completed in less than a day, it should be broken up into multiple issues.
  • Make pull requests from your own forks (even if you have write rights to the repository, do not create new branches, develop on your own branches).
  • State the actual change or enhancement in the commit message of PRs (do not just state “Fixes issue #123”).
  • Add the issue number into the description (this helps to speed up reviews as reviewers can simply click to get more info in the issue itself).
  • Write clear meaningful git commit messages (Do read http://chris.beams.io/posts/git-commit/).
  • Match pull requests with issues and make sure your pull requests description contains GitHub’s special keyword references that automatically close the related issue when the pull request is merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests).
  • When you make very minor changes to a pull request of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don’t have an absurd number of commits for a very small fix (Learn how to squash at https://davidwalsh.name/squash-commits-git).
  • Add a screenshot if you changed anything in the UI of a project. When you’re submitting a pull request for a UI-related issue, please add a screenshot of your change or a link to a deployment where it can be tested out along with your pull request. It makes it much easier for the reviewers and helps to speed up the process. You’ll also get reviews quicker.
  • Add a link to your deployment of the project, where reviewers can check out what you have changed (especially for smaller changes this is very helpful as the reviewer might not even need to set up the system itself and test it. Again this speeds up the review process a lot).
  • Always ensure CI and tests are successful.
  • Help to resolve merge conflicts (especially if there are several PRs at the same time, merge conflicts are common. Help the reviewers and solve merge conflicts to speed up the process.).
  • Merging Pull Requests should only happen if at least two contributors reviewed the PR and approved it.

Scope of Issues and Commits

  • Stay focused on the issue and its specifics: Sometimes it is tempting to do more changes in a pull request and simply add a nice little feature after mentioning it in the issue tracker. Please do not do this. Contributors will look at the title of issues usually to check if it is relevant for them. For example, if an issue is about changing a font, do not also change the color even if this seems like small change to you. Many projects have a design template and standard colors etc. that they want to achieve. So your changes might need to be discussed in a bigger setting even if they seem small to you. Same applies to many other areas.
  • Do only the changes in a pull request that are mentioned in the issue. Do not change anything else without ever mentioning it (remember match issues with pull requests).

Branch Policies

Most FOSSASIA Projects have:

  • a development branch (which is the working branch. Please commit to this branch.) and
  • a master branch (which is the stable branch).

Some projects also keep additional branches e.g.:

  • gh-pages for documentation purposes (often autogenerated from md-files in docs folder)
  • apk branches for Android apps (often autogenerated with travis).

Getting Started

  • Newcomers are sometimes afraid to make a pull request. Don’t be! It is the responsibility of reviewers to review them. And Git is a beautiful tool when it comes to reverting pull requests with errors.
  • In simple issues keep it simple and “simply” contribute, e.g. in an issue “change the color of the button from green to red”, there is no need to mention and ask “here is a screenshot where I changed the color to red. Should I make a PR now?”. Just make the pull request and wait for the feedback of the reviewer.
  • Take on responsibility early and help to review other contributions. Even though you do not have write access in a repository you can already help to review other commits.

Documentation

  • Please ensure you provide information about your code and the functioning of your app as part of every code contribution.
  • Add information on technologies and the code into the code itself and into documentation files e.g. into the Readme.md or /docs folder. Documentation is not a thing that should be done at the end after a few weeks or months of coding! Documentation is a continuous effort at every step of software development.
  • If you add new libraries or technologies add information about them into the Readme file.
  • If you implement a different design or change the css in a web project, please add information to the design specifications/template. If there are not any design specifications in the project yet, why not start them and add a section into the Readme.md to start with?
  • Always help to keep documentation up to date and make it easy for new contributors to join the project.

 

Thank you for helping to define many of the practices while working on the Open Event project to the developer team and for additional input and links to Niranjan Rajendran.

Links to Other Resources

Continue ReadingOpen Source Developer Guide and Best Practices at FOSSASIA
Read more about the article Apply for Your Free Stay during the FOSSASIA Summit 2017 with our 100 #OpenTechNights Program
FOSSASIA OpenTechSummit 2016. http://2016.fossasia.org/

Apply for Your Free Stay during the FOSSASIA Summit 2017 with our 100 #OpenTechNights Program

The FOSSASIA Summit 2017 takes place from Friday March 17 – Sunday March 19 at the Science Centre Singapore. We are now inviting Open Source contributors to apply for a free stay in a Singapore hostel and a free ticket to the event. All you have to do is convince us, that you are an awesome Open Source contributor!

The details

Developers from all over the world are joining the FOSSASIA Summit. We want to connect established and new Open Tech contributors alike. Therefore FOSSASIA is supporting the Open Source community to join the event by offering 100 free nights stay at a hostel in the centre of Singapore and a free ticket to the event. All you have to do is to fill in the form with information that convinces us that you are an awesome contributor in the Open Source community.

The Process

Step 1: Please fill in our form here before February 17 (23:00 Singapore Time).

Step 2: We will get back to you at latest within 3 days after the deadline if you are selected. But, also we are choosing very convincing applicants on an ongoing basis. So, the earlier you apply the higher your chances to get a free stay might be.

Step 3: The selected applicants will need to confirm their itinerary and tickets before March 1st to re-assure their free stay in Singapore.

Expectations of Participants – Share what you learn

1. Please support volunteers, speakers and participants at the event. Let’s bring all this good spirit of sharing Open Technologies and learning together!

2. Help to reach out to participants who cannot join us at the event. For example make some tweets, share what you learn on social media, publish photos and put up blog posts about the summit.

Our Team

Our team of “100 #OpenTechNights” – Hong Phuc Dang, Mario Behling, and Roland Turner – is excited to meet you in Singapore!

Apply Now

Apply for a free stay with #FOSSASIA #OpenTechNights and participation at the FOSSASIA Summit 2017 now here!

More Information

More updates, tickets and information on speakers also on our #OpenEvent system: https://eventyay.com/e/45da88b7/

Continue ReadingApply for Your Free Stay during the FOSSASIA Summit 2017 with our 100 #OpenTechNights Program
Read more about the article Join Codeheat Coding Contest 2016/17

Join Codeheat Coding Contest 2016/17

In the Heat of the Code is a coding contest supported by the UNESCO to involve new contributors in Open Source projects. Participating projects are:

1. The Open Event Orga Server using Python/flask.
2. The SUSI.AI repositories with a focus on the SUSI.AI Android App and SUSI Messenger Bots, and
3. The loklak repositories with a focus on loklak search with AngularJS.

The contest runs until 3rd February 2017. Grand prize winners will be invited to present their work at the FOSSASIA Summit at the Science Centre Singapore from March 17th -19th 2017 and will get up to 450 USD in travel funding to attend, plus a free speaker ticket.

codeheat-logo

Our jury will choose three winners from the top 10 contributors according to code quality and relevance of commits for the project. The jury also takes other contributions like submitted scrum reports and technical blog posts into account, but of course awesome code is the most important item on the list. Other participants will have the chance to win vouchers to attend Open Tech events in the region and will get certificates of participation. Sign up here now.

A team of over 30 mentors and jury members from 10 different countries supports participants of the contest.

Participants should take the time to read through the contest FAQ and familiarize themselves with the introductory information and Readme.md of each project before starting work on an issue.

The website codeheat.org has a list of questions and answers. Developers interested in the contest can also contact mentors on our Slack channel [Get a Slack Invite].

If you make at least four commits labeled “hacktoberfest” before 31st October you can also win a Hacktoberfest T-shirt (additional sign up required here).

Continue ReadingJoin Codeheat Coding Contest 2016/17

Twitter Oauth

Oauth_logo.svg.png

What is Oauth?

It’s an open protocol which allows to secure an authorization in a simple and standard method from web, mobile and desktop applications.Facebook, Google Twitter, Github and more web services use this protocol to authenticate user. Using Oauth is very convenient, because it delegates user authentication to the service which host user account. It allows us to get resources from another web service without giving any login or password. If you have a service and want to prepare a authentication via Twitter, the best solution is to use OAuth. Recently Open Event team met a problem in an user profile page. We’d like to automatically fill information about user. Of course, to solve it we use Oauth protocol, to authenticate with Twitter After a three-steps authentication we can get name and profile picture.If you need another information from Twitter profile like recent tweets or followers’ list. You have to visit Twitter API site to see more samples of resource which you can get

How do Open event team implement communication between Orga-server and Twitter?

All services have a very similar flow. Below i will show you how it looks in our case.

Before starting you need to create your own twitter app. You can create app in Twitter apps site https://apps.twitter.com/. If  create an app you will see a CONSUMER KEY and CONSUMER SECRET KEY which shouldn’t be human-readable, so remember not to share these keys.

Below example shows how to get basic information about twitter profile

We use oauth2 python library https://github.com/joestump/python-oauth2

consumer = oauth2.Consumer(key=TwitterOAuth.get_client_id(),

                          secret=TwitterOAuth.get_client_secret())

client = oauth2.Client(consumer)

TwitterOAuth.get_client_id() – CONSUMER KEY

TwitterOAuth.get_client_secret()  – CONSUMER SECRET KEY

Then we send GET request to request_token endpoint to get oauth_token

client.request('https://api.twitter.com/oauth/request_token', "GET")
Response: oauth_token=Z6eEdO8MOmk394WozF5oKyuAv855l4Mlqo7hhlSLik&
oauth_token_secret=Kd75W4OQfb2oJTV0vzGzeXftVAwgMnEK9MumzYcM&
oauth_callback_confirmed=true

Next step is to redirect user to Twitter Authentication site

twitter-oauth.png

You can see in an url a redirect_uri. So after sign in Client will get a callback from Twitter with oauth_verifier and oauth_token params

https://api.twitter.com/oauth/authenticate?oauth_token=RcYGqAAAAAAAwdbbAAABVoM1UMo&oauth_token_secret=wZfpPpCugAmdF3AuohEnvBTRxdCmllxu&oauth_callback_confirmed=true&redirect_uri=http://open-event-dev.herokuapp.com/tCallback

The last step is to get an access token. If we have an oauth_verifier and an oauth_token it’s pretty easy 

def get_access_token(self, oauth_verifier, oauth_token):

   consumer = self.get_consumer()

   client = oauth2.Client(consumer)

   return client.request(

       self.TW_ACCESS_TOKEN_URI + 'oauth_verifier=' + oauth_verifier + 
       "&oauth_token=" + oauth_token, "POST")

Where TW_ACCESS_TOKEN_URI is https://api.twitter.com/oauth/access_token

Final step is to get our user information

resp, content = client.request("https://api.twitter.com/1.1/users/show.json?
                               screen_name=" + access_token["screen_name"] +
                               "&user_id=" + access_token["user_id"] , "GET")

user_info = json.loads(content)

In an user_info variable you can get a profile picture or a profile name.

Summarizing, oauth protocol is very secure and easy to use by developer. At the beginning an oauth flow can seem to be a little hard to  understand but if you spend some time trying tp understand it, everything becomes easier.  And it’s secured. because you don’t need to store a login or a password, and an access token has an expired time. This is the main feature of Oauth protocol.

Continue ReadingTwitter Oauth

Unit Testing

There are many stories about unit testing. Developers sometimes say that they don’t write tests because they write a good quality code. Does it make sense, if no one is infallible?.

At studies only a  few teachers talk about unit testing, but they only show basic examples of unit testing. They require to write a few tests to finish final project, but nobody really  teaches us the importance of unit testing.

I have also always wondered what benefits can it bring. As time is a really important factor in our work it often happens that we simply resign of this part of process development to get “more time” rather than spend time on writing stupid tests. But now I know that it is a vicious circle.

Customers requierments does not help us. They put a high pressure to see visible results not a few statistics about coverage status. None of them cares about some strange numbers. So, as I mentioned above, we usually focuses on building new features and get riid of tests. It may seem to save time, but it doesn’t.

In reality tests save us a lot of time because we can identify and fix bugs very quickly. If a bug ocurrs because someone’s change we don’t have to spend long hours trying to figure out wgat is going out. That’s why we need tests.  

It is especially visible in huge open source projects. FOSSASIA organization has about 200 contributors. In OpenEvent project we have about 20 active developers, who generate many lines of code every single day. Many of them change over and over again as well as interfere  with each other.

Let me provide you with a simple example. In our team we have about 7 pull requests per day. As I mentioned above we want to make our code high quality and free of bugs, but without testing identifying if pull request causes a bug is very difficult task. But fortunately this boring job makes Travis CI for us. It is a great tool which uses our tests and runs them on every PR  to check if bugs occur. It helps us to quickly notice bugs and maintain our project very well.

What is unit testing?

Unit testing is a software development method in which the smallest testable parts of an application are tested

Why do we need writing unit tests?

Let me point all arguments why unit testing is really important while developing a project.

  • To prove that our code works properly

If developer adds another condition, test checks if method returns correct results. You simply don’t need to wonder if something is wrong with you code.

  • To reduce amount of bugs

It let you to know what inputs params’ function should get and what results should be returned. You simply don’t  write unused code

  • To save development time

Developers don’t waste time on checking every code’s change if his code works correctly

  • Unit tests help to understand software design
  • To provide quick feedback about method which you are testing
  • To help document a code

How to write unit test in Python

In my work I write use tests in Python. I am going to share my sample code  with you now

  • Import module unittest
  • Choose function to test
  • Write unit test

Example OpenEvent test in Python

class TestPagesUrls(OpenEventTestCase):

   def setUp(self):

       self.app = Setup.create_app()

   def test_if_urls_exist(self):

       """Test all urls via GET method"""

       with app.test_request_context():

           for rule in app.url_map.iter_rules():

               if excluded_paths(rule):

                   status_code = self.app.get(request.url[:-1] + str(rule).replace('//', '/'),        follow_redirects=True).status_code

                   self.assertTrue(status_code in [200, 302, 401])

 

I want to check if all views exist but it required a lot of time. That’s why I wonder I how to avoid writing similar tests. Finally, based  on our list of routes I am able to write test which checks code’s status  on every page.

If some of them response returns status_code different than 200, 302 or 401, test fails.This results means that somethings is wrong. Simple, isn’t it ?  Try to test it manually…. This one short test cover about 40 use cases…

This example shows an incredible value of unit tests! If developer makes a bug in response he receives an error that something is wrong with a view. Travis CI allows to reject all  wrong pull requests and merge only these which fulfill our quality requirements.   

Fixing  error is one part but finding a bug is even harder task. But an ability to detect bug on early stage of process development reduces cost of software.

 

Continue ReadingUnit Testing

Vote for Open Event in Google Impact Challenge

Please vote for Open Event in the Google Impact Challenge: https://impactchallenge.withgoogle.com/deutschland/charity/lxde

The idea of Open Event is to give organizers and participants a tool to plan events and distribute information to attendees. We are working on an organizers server and mobile apps (https://github.com/fossasia/open-event).

Your vote for Open Event will support the development of the project. Thank you!

Continue ReadingVote for Open Event in Google Impact Challenge
Read more about the article Participate in FOSSASIA Summit 2016 in Science Center Singapore, March 18th-20th

Participate in FOSSASIA Summit 2016 in Science Center Singapore, March 18th-20th

Please join us at FOSSASIA 2016 in Singapore, the premier Open Technology event in Asia.

The event will take place from March 18-20 at the Singapore Science Center and already on 17th March the pgDay Asia conference is part of the pre-event activities.

The FOSSASIA weekend from Friday to Sunday is dedicated to the “Internet of Things and Me” covering open technologies and software that make todays connected devices run. In workshops kids can start learning with the Pocket Science Lab. In the Science Hack track attendees will learn how to participate in the Citizen Science community. Please:

More than 120 speakers from Asia and around the world will join the event from communities and companies such as Google, RedHat, and Github. There will be talks and hands on workshops on topics including:

  • Open Hardware, Makers, Internet of Things
  • Open Source Software, Data and Free Knowledge
  • DevOps, Docker, Programming languages, Python, Go, and more
  • Science Hacks and Open Design
  • Tech and Science for Kids

Info on the FOSSASIA Summit 2016 at the Event Website

Read the Call for Speakers here.

Join the FOSSASIA Meetup Group in Singapore and reserve your spot in workshops as soon as they are announced.

Follow us on Twitter.

Check out the photos from last year on Flickr.

Continue ReadingParticipate in FOSSASIA Summit 2016 in Science Center Singapore, March 18th-20th
Read more about the article OpenTech and Open Knowledge in the Mekong Delta and throughout Asia

OpenTech and Open Knowledge in the Mekong Delta and throughout Asia

The FOSSASIA organization has been very active and I would love to give you a few updates on our activities. One thing why we love to work in this community is because you get the chance to meet some of the most awesome and friendly tech people of the world. Jonas Smeedegaard from the Debian community is one of our guests who has been visiting us three times already and conducted workshops at our events and even stayed several weeks in Can Tho to train students using and developing Debian.

Jonas Smeedegaard at Workshop: Bringing Asian and International developers together

Meetups and Code Sprints

Of course we could not do all of this alone and we would like to thank some of the most outstanding folks we are working together with including HanoiLUG and Saigonlug in Vietnam, Singapore Hackerspace and the Beijinglug.

Coding Projects

We have recently involved and organized activities with the following projects and are glad to feature the following projects on this blog:

  • Wikipedia
  • OpenWrt
  • Crypto-Stick
  • LXDE
  • MoonOS
  • Android
  • GNOME
  • Debian
  • Fedora
  • Gimp
  • Inkscape
  • Linux conversion libraries
  • OpenStreetMap
  • and many more

FOSSASIA Event in Ho Chi Minh City

Internships

In 2012 we welcomed interns in Can Tho. Fifteen students participated in the program as full time interns in the office of MBM International in the biggest city in the Mekong delta. The program took place for 2 months and a core part of it was to learn how to use collaborative tools liker issue trackers and contribute to OpenStreetMap. Our students also love the Wikipedia sprints and we got a lot of positive vibes as everyone was happy to learn how to set up the Mediawiki software, that empowers the encyclopedia, share their ideas and spread Open Knowledge and Open Data about the Mekong Delta.

Event activities

We also continued to organize the FOSSASIA OpenTechSummit in 2010 and 2011 in Raffles College and Van Lang University in Ho Chi Minh City Vietnam. Plus we had a Mini-Debconf in Saigon and organized the event series OpenDesign.Asia Weeks bringing together designers and Open Source developers. We have links to the LXDE project and GNOME community and we have sent developers to the GNOME.Asia Summit 2012 in Hong Kong and supported the TYPO3 conference 2012 in Phnom Penh.

Also globally FOSSASIA starts to receive more attention. We have received the opportunity to introduce Asian projects at the Libre Graphics Meeting in Montreal (2011) and Brussels (2011), at the Linuxtag in Berlin (2012) and many other community events.

Please Join us and Get in Touch

The FOSSASIA organization supports activities and Open Tech development and Open Knowledge projects of the community active in Asia. If you are interested to cooperate for a project, need support for a development sprint or an event, please contact us on the FOSSASIA mailing list: http://groups.google.com/group/fossasia

 

Continue ReadingOpenTech and Open Knowledge in the Mekong Delta and throughout Asia

Open Design Weeks 2011 Saigon

The Open Design Weeks Asia take place in Hochi Minh City and Cantho (Vietnam) from April 2-16, 2011. The program has been announced. There will be an Open Design Camp in Saigon and intensive workshops in Cantho.

The focus of the Open Design Weeks are on design, Free, Libre and Open Source software, open content and Free Culture practices. Events during the design weeks include workshops, design camps to share expertise an unconference, company meet ups to establish international cooperations, presentations in Universities and training workshops. The intensive workshops with local designers, software developers and typographers focus on collaborative font design, mapping and publication.

This will be a great chance to get involved in some new and exciting projects

Open Design Weeks: http://opendesign.asia

Continue ReadingOpen Design Weeks 2011 Saigon

How to get contributors from Asia for your Open Source project – Talk at Libre Graphics Meeting Brussels

I had the chance to talk about the topic of how to get contributors for Free/Libre/Open Source projects from Vietnam and Asia at the Libre Graphics Meeting Brussels. It was a a fantastic experience to meet developers and contributors from all over the world and I hope to support projects with the insights of this talk.

The situation in 2010 in Asia is, that many people still do not know about Free and Open Source. We need more people to support each other and help new users und developers. We need more developers in Vietnam to adapt existing solutions for Vietnamese and Asian users. We need people to organize events, where we can meet face to face. We need mentors, who developers and contributors can turn to. We need business people who understand business models and opportunities around Free and Open Source. We need you! FOSS can be a sustainable model for Vietnam as it is for other countries. Please join us in our effort for education, spreading knowledge, developement of better, faster and energy-saving software, designing easy to use interfaces and promoting opportunities for everyone with Free and Open Source.

Links

* Libre Graphics Meeting 2010: http://libregraphicsmeeting.org/2010

* LGM: http://libregraphicsmeeting.org

 

Continue ReadingHow to get contributors from Asia for your Open Source project – Talk at Libre Graphics Meeting Brussels